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

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

Arquitetura

A arquitetura tem os seguintes componentes.

O diagrama mostra uma rede virtual composta por seis sub-redes: gateway de aplicativo, gerenciamento, camada da Web, camada de negócios, camada de dados e Active Directory. A sub-rede da camada de dados usa a testemunha de nuvem. Há três balanceadores de carga.

Geral

  • Grupo de recursos. Os grupos de recursos são usados para agrupar recursos do Azure para que possam ser gerenciados por tempo de vida, 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 dentro de um carimbo de Azure Stack Hub garante que, durante um evento de manutenção planejada ou não planejada, pelo menos uma máquina virtual esteja disponível. As VMs são colocadas em um conjunto de disponibilidade que as espalha em vários domínios de falha (Azure Stack hosts de Hub)

Rede e balanceamento de carga

  • 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 o gateway de aplicativo ainda não está disponível no Hub de Azure Stack, há alternativas disponíveis no mercado de Azure Stack local , como: Kemp loadmestre Load Balancer ADC Content switchF5 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 de rede 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 Hub de Azure Stack não fornece seu próprio serviço de Hospedagem de DNS, portanto, use o servidor DNS em seu ADDS.

Máquinas virtuais

  • SQL Server Always On grupo de disponibilidade. 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 AD DS servidores em VMs na mesma rede virtual são o método preferencial para unir outras VMs a AD DS. você também pode unir as VMs a AD DS de Enterprise existentes conectando a rede virtual a Enterprise rede com a conexão VPN. com ambas as abordagens, você precisa alterar o DNS da rede virtual para seu servidor dns AD DS (em rede virtual ou rede Enterprise existente) para resolver o FQDN do domínio 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 tem apenas dois nós, uma partição de rede pode fazer com que cada nó pense que é o principal. 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 Hub Azure Stack, o ponto de extremidade de testemunha de nuvem é diferente do Azure global.

Pode ser semelhante a:

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

  • Para 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 Windows no Hub Azure Stack.

Rede virtual

Ao 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 à sua rede local, caso você precise configurar um gateway entre a rede virtual e a rede local mais tarde. Depois de criar a rede virtual, você não pode 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, consulte planejar e projetar 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 à Load Balancer de camada 7.

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. Negar todo o tráfego de entrada da rede virtual. (Use a marca de 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-4 com prioridade mais alta do que a primeira regra, para que elas a substituam.

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 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.

Observação

Quando o IP flutuante está habilitado, o número da porta de front-end deve ser igual ao número da porta de back-end na regra do balanceador de carga.

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 seu aplicativo fizer mais leituras do que gravações, você poderá descarregar algumas das consultas somente leitura em uma réplica secundária. 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 SQL otimização de desempenho, você também pode consultar o artigo SQL práticas recomendadas do servidor 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 passar pelo 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 dimensionar facilita a implantação e o gerenciamento de um conjunto de VMs idênticas. Considere os conjuntos de dimensionar se você 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 Azure Stack Hub, no entanto, há algumas advertências:

  • Os conjuntos de dimensionamento de máquinas virtuais Azure Stack Hub não são suportados por excesso deprovisionamento ou atualizações sem distribuição.

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

  • É recomendável usar discos gerenciados em 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 Azure Stack Hub, VMs individuais e instâncias do conjunto de dimensionamento.

Limites de assinatura

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

Considerações sobre segurança

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

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

DMZ. 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