Aplicativo de N camadas do Windows no Azure Stack Hub com SQL Server

Essa arquitetura de referência mostra como implantar VMs (máquinas virtuais) e uma rede virtual configurada para um aplicativo de N camadas usando o SQL Server no Windows para a camada de dados.

Arquitetura

A arquitetura tem os seguintes componentes.

Geral

• Grupo de recursos. Grupos de recursos são utilizados para agrupar recursos do Azure para que eles possam ser gerenciados pelo tempo de vida, o proprietário ou outros critérios.

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

Balanceamento de carga e rede

• Rede virtual e sub-redes. Cada VM do Azure é implantada em uma rede virtual que pode ser segmentada em sub-redes. Sempre crie uma sub-rede separada para cada camada.

• Camada 7 Load Balancer. Como Gateway de Aplicativo ainda não está disponível no Azure Stack Hub, há alternativas disponíveis no Azure Stack Hub Market, como: KEMP LoadMaster Load Balancer ADC Content Switch/ f5 Big-IP Virtual Edition ou A10 vThunder ADC

• Balanceadores de carga. Use Azure Load Balancer para distribuir o tráfego de rede da camada da Web para a camada de negócios e da camada de negócios para SQL Server.

• NSGs (Grupos de Segurança de Rede). Use NSGs para restringir o tráfego na rede virtual. Por exemplo, na arquitetura de três camadas mostrada aqui, a camada de banco de dados não aceita o tráfego de front-end da Web, somente da camada comercial e da sub-rede de gerenciamento.

• DNS. O Azure Stack Hub não fornece seu próprio serviço de hospedagem DNS, portanto, use o servidor DNS em seu ADDS.

Máquinas virtuais

• Grupo de Disponibilidade Always On do SQL Server. Fornece alta disponibilidade na camada de dados, habilitando replicação e failover. Usa a tecnologia WSFC (Cluster de Failover do Windows Server) para o failover.

• Servidores AD DS (Active Directory Domain Services). Os objetos de computação do cluster de failover e suas funções em cluster associadas são criados no Active Directory Domain Services (AD DS). Configurar servidores AD DS em VMs na mesma rede virtual é o método preferencial para unir outras VMs ao AD DS. Você também pode unir as VMs ao Enterprise AD DS existente conectando a rede virtual à rede enterprise com conexão VPN. Com ambas as abordagens, você precisa alterar o DNS da rede virtual para o servidor DNS do AD DS (na rede virtual ou na rede Enterprise existente) para resolve o FQDN de domínio do AD DS.

• Testemunha de Nuvem. Um cluster de failover requer mais da metade dos seus nós em execução, que é conhecido como ter quorum. Se o cluster tiver apenas dois nós, uma partição de rede poderá fazer com que cada nó pense que é o nó do painel de controle. Nesse caso, é necessário uma testemunha para desempatar e estabelecer o quorum. Testemunha é um recurso, como um disco compartilhado, que pode agir como um desempate para estabelecer o quorum. A Testemunha de Nuvem é um tipo que usa o Armazenamento de Blobs do Azure. Para saber mais sobre o conceito de quorum, consulte Entendendo o cluster e o quorum de pool. Para obter mais informações sobre a Testemunha de Nuvem, consulte Implantar uma Testemunha de Nuvem para um Cluster de Failover. No Azure Stack Hub, o ponto de extremidade testemunha de nuvem é diferente do Azure global.

Pode parecer com:

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

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

• Jumpbox. Também chamada de um host bastião. Uma VM protegida na rede que os administradores usam para se conectar às outras VMs. O jumpbox tem um NSG que permite o tráfego remoto apenas de endereços IP públicos em uma lista segura. O NSG deve permitir o tráfego de RDP (área de trabalho remota).

Recomendações

Seus requisitos podem ser diferentes dos requisitos da arquitetura descrita aqui. Use essas recomendações como ponto de partida.

Máquinas virtuais

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

Rede virtual

Quando você criar a rede virtual, determine quantos endereços IP seus recursos em cada sub-rede exigem. Especifique uma máscara de sub-rede e um intervalo de endereços de rede grande o suficiente para os endereços IP necessários, usando a notação CIDR. Use um espaço de endereço que esteja dentro dos blocos de endereço 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 ao da rede local para caso seja necessário configurar um gateway entre a rede virtual e a rede local mais tarde. Depois de criar a rede virtual, você não poderá alterar o intervalo de endereços.

Crie as sub-redes levando em conta os requisitos de funcionalidade e de segurança. Todas as VMs na mesma camada ou função devem ir para a mesma sub-rede, que pode ser um limite de segurança. Para obter mais informações sobre como criar redes virtuais e sub-redes, confira Planejar e criar redes virtuais do Azure.

Balanceadores de carga

Não exponha as VMs diretamente à Internet, concedendo, em vez disso, um endereço IP privado a cada VM. Os clientes se conectam usando o endereço IP público associado à camada 7 Load Balancer.

Defina as regras do balanceador de carga para direcionar tráfego de rede para as VMs. Por exemplo, para permitir tráfego HTTP, mapeie a porta 80 da configuração de front-end para a porta 80 no pool de endereços de back-end. Quando um cliente envia uma solicitação HTTP para a porta 80, o balanceador de carga seleciona um endereço IP de back-end usando um algoritmo de hash que inclui o endereço IP de origem. As solicitações de cliente são distribuídas por todas as VMs no pool de endereços de back-end.

Grupos de segurança de rede

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

1. Negue todo o tráfego de entrada da rede virtual. (Use a marca VIRTUAL_NETWORK na regra.)

2. Permita o tráfego de entrada da sub-rede de camada de negócios.

3. Permita o tráfego de entrada da própria sub-rede de camada de dados. Essa regra permite a comunicação entre as VMs de banco de dados, que é necessária para failover e replicação de banco de dados.

4. Permita o tráfego RDP (porta 3389) da sub-rede jumpbox. Essa regra permite que os administradores se conectem à camada de banco de dados do jumpbox.

Crie regras 2 a 4 com prioridade mais alta do que a primeira regra, portanto, elas a substituem.

Grupos de Disponibilidade Always On do SQL Server

Recomendamos usar os Grupos de Disponibilidade Always On para alta disponibilidade no SQL Server. Antes do Windows Server 2016, os Grupos de Disponibilidade Always On exigiam um controlador de domínio e todos os nós no grupo de disponibilidade precisavam estar no mesmo domínio do AD.

Para alta disponibilidade da camada de VM, todas as VMs do SQL devem estar em um Conjunto de Disponibilidade.

Outras camadas se conectam ao banco de dados por meio de um ouvinte do grupo de disponibilidade. O ouvinte permite que um cliente SQL se conecte sem saber o nome da instância física do SQL Server. VMs que acessam o banco de dados precisam ser ingressadas no domínio. O cliente (neste caso, outra camada) usa o DNS para resolver o nome da rede virtual do ouvinte em endereços IP.

Configure um grupo de disponibilidade Always On do SQL Server da seguinte maneira:

1. Crie um cluster WSFC (Clustering de Failover do Windows Server), um Grupo de Disponibilidade Always On do SQL Server e uma réplica primária. Para obter mais informações, consulte Introdução aos Grupos de disponibilidade Always On.

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

3. Crie um ouvinte do grupo de disponibilidade e mapeie o nome DNS do ouvinte para o endereço IP de um balanceador de carga interno.

4. Crie uma regra do balanceador de carga para a porta de escuta do SQL Server (porta TCP 1433 por padrão). A regra do balanceador de carga deve habilitar IP flutuante, também chamado de Retorno de Servidor Direto. Isso faz com que a VM responda diretamente para o cliente, o que permite uma conexão direta com a réplica primária.

Quando um cliente SQL tenta se conectar, o balanceador de carga roteia a solicitação de conexão para a réplica primária. Se houver um failover para outra réplica, o balanceador de carga encaminhará automaticamente as novas solicitações para uma nova réplica primária. Para obter mais informações, consulte Configurar um ouvinte de ILB para Grupos de Disponibilidade Always On do SQL Server.

Durante um failover, as conexões de cliente existentes são fechadas. Após a conclusão do failover, novas conexões serão roteadas para a nova réplica primária.

Se o aplicativo fizer mais leituras do que gravações, você poderá descarregar algumas das consultas somente leitura para um réplica secundário. Consulte Usar um ouvinte para se conectar a uma réplica secundária somente leitura (roteamento somente leitura).

Teste a implantação por forçando um failover manual do grupo de disponibilidade.

Para otimização de desempenho do SQL, você também pode consultar o artigo Práticas recomendadas do SQL Server para otimizar o desempenho no Azure Stack Hub.

Jumpbox

Não permita o acesso RDP da Internet pública para as VMs que executam a carga de trabalho do aplicativo. Em vez disso, todo o acesso RDP a essas VMs deve ocorrer por meio do jumpbox. Um administrador faz logon no jumpbox e, em seguida, faz logon na VM por meio do jumpbox. O jumpbox permite que tráfego RDP da Internet, mas apenas de endereços IP conhecidos e seguros.

O jumpbox tem requisitos de desempenho mínimo, por isso, selecione uma VM de tamanho pequeno. Crie um endereço IP público para o jumpbox. Coloque o jumpbox na mesma rede virtual que as outras VMs, mas em uma sub-rede de gerenciamento separada.

Para proteger o jumpbox, adicione uma regra NSG que permite conexões RDP somente de um conjunto seguro de endereços IP públicos. Configure os NSGs para outras sub-redes para permitir o tráfego RDP da sub-rede de gerenciamento.

Considerações sobre escalabilidade

Conjuntos de dimensionamento

Para as camadas Web e comercial, considere o uso de conjuntos de dimensionamento de máquinas virtuais, em vez de implantar VMs separadas. Um conjunto de dimensionamento facilita a implantação e o gerenciamento de um conjunto de VMs idênticas. Considere os conjuntos de dimensionamento se precisar escalar rapidamente as VMs.

Há duas maneiras básicas de configurar as VMs implantadas em um conjunto de dimensionamento:

• Use as extensões para configurar a VM depois que ela é implantada. Com essa abordagem, novas instâncias de VM podem levar mais tempo para ser iniciadas do que uma VM sem extensões.

• Implante um disco gerenciado com uma imagem de disco personalizada. Essa opção pode ser mais rápida de implantar. Porém, isso requer que você mantenha a imagem atualizada.

Para obter mais informações, confira Considerações de design para conjuntos de dimensionamento. Essa consideração de design é principalmente verdadeira para o Azure Stack Hub, no entanto, há algumas advertências:

• Os conjuntos de dimensionamento de máquinas virtuais no Azure Stack Hub não dão suporte ao excesso de provisionamento nem a atualizações sem interrupção.

• Não é possível dimensionar automaticamente conjuntos de dimensionamento de máquinas virtuais no Azure Stack Hub.

• É altamente recomendável usar discos gerenciados no Azure Stack Hub em vez de discos não gerenciados para o conjunto de dimensionamento de máquinas virtuais

• Atualmente, há um limite de 700 VMs no Azure Stack Hub, que é responsável por todas as VMs de infraestrutura do Azure Stack Hub, VMs individuais e instâncias de conjunto de dimensionamento.

Limites de assinatura

Cada assinatura de locatário do Azure Stack Hub tem limites padrão em vigor, incluindo um número máximo de VMs por região configurada pelo operador do Azure Stack Hub. Para obter mais informações, consulte Visão geral dos serviços, planos, ofertas e assinaturas do Azure Stack Hub. Consulte também Tipos de cota no Azure Stack Hub.

Considerações de segurança

Redes virtuais são um limite de isolamento de tráfego no Azure. Por padrão, as VMs de uma rede virtual não podem se comunicar diretamente com as VMs de rede virtual diferente.

NSGs. Use NSGs (grupos de segurança de rede) para restringir o tráfego de entrada e saída para a Internet. Para obter mais informações, consulte Serviços em nuvem da Microsoft e segurança de rede.

REDE DE PERÍMETRO. Considere adicionar uma NVA (solução de virtualização de rede) para criar uma DMZ entre a Internet e a rede virtual do Azure. NVA é um termo genérico para uma solução de virtualização que pode executar tarefas relacionadas à rede, como firewall, inspeção de pacotes, auditoria e roteamento personalizado.

Criptografia. Criptografe dados confidenciais em repouso e use Key Vault no Azure Stack Hub para gerenciar as chaves de criptografia de banco de dados. Para saber mais, consulte Configurar a Integração do Cofre de Chaves do Azure para o SQL nas VMs do Azure. Também é recomendado para armazenar segredos do aplicativo, como cadeias de caracteres de conexão de banco de dados, no cofre de chaves.

Próximas etapas

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