Windows aplicação n-tier no Azure Stack Hub com SQL Server

Esta arquitetura de referência mostra como implantar máquinas virtuais (VMs) e uma rede virtual configurada para uma aplicação de nível N, usando SQL Server em Windows para o nível de dados.

Arquitetura

A arquitetura é composta pelos seguintes componentes:

The diagram shows a virtual network comprising six subnets: Application Gateway, Management, Web tier, Business tier, Data tier, and Active Directory. The Data tier subnet uses Cloud Witness. There are three load balancers.

Geral

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

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

Equilíbrio em rede e carga

  • Rede virtual e sub-redes. Cada VM Azure é implantado numa rede virtual que pode ser segmentada em sub-redes. Crie uma sub-rede separada para cada camada.

  • Balanceador de carga camada 7. Como o Application Gateway ainda não está disponível no Azure Stack Hub, existem alternativas disponíveis no Azure Stack Hub Market, tais como: KEMP LoadMaster Load Balancer ADC Content Switchf5 Big-IP Virtual Edition ou A10 vThunder ADC

  • Equilibradores de carga. Utilize Balanceador de Carga do Azure para distribuir o tráfego de rede do nível web para o nível de negócio, e do nível de negócio para SQL Server.

  • Grupos de segurança de rede (NSGs). Utilize NSGs para restringir o tráfego de rede dentro da rede virtual. Por exemplo, na arquitetura de três camadas aqui mostrada, o nível de base de dados não aceita o tráfego a partir da extremidade frontal da web, apenas a partir do nível 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 hospedagem DNS, por isso, por favor, utilize o servidor DNS nos seus ADDS.

Máquinas virtuais

  • SQL Server Sempre No Grupo de Disponibilidade. Fornece uma elevada disponibilidade na camada de dados ao ativar a replicação e a ativação pós-falha. Utiliza Windows tecnologia de failover cluster (WSFC) para falha.

  • Servidores do Active Directory Domain Services (AD DS). Os objetos de computador para o cluster failover e as suas funções agrupadas associadas são criados em Ative Directory Domain Services (AD DS). Configurar servidores AD DS em VMs na mesma rede virtual são métodos preferidos para se juntar a outros VMs a DS AD. Também pode juntar os VMs à Empresa AD DS existente, ligando a rede virtual à rede Enterprise com a ligação VPN. Com ambas as abordagens, é necessário alterar o DNS de rede virtual para o seu servidor DS DNS AD (em rede virtual ou rede Enterprise existente) para resolver o domínio AD DS FQDN.

  • Cloud Witness. Um aglomerado de falhanços requer que mais de metade dos seus nós estejam a funcionar, que é conhecido como tendo quórum. Se o cluster tem apenas dois nós, uma divisória de rede pode fazer com que cada nó pense que é o nó principal. Nesse caso, precisas de uma testemunha para quebrar laços e estabelecer quórum. Uma testemunha é um recurso como um disco partilhado que pode funcionar como um desempate para estabelecer quórum. Cloud Witness é um tipo de testemunha que usa Azure Blob Armazenamento. Para saber mais sobre o conceito de quórum, consulte o cluster understanding e o quorum da piscina. Para obter mais informações sobre cloud witness, consulte Implementar uma Testemunha em Nuvem para um Cluster de Falhas. Em Azure Stack Hub, o ponto final cloud Witness é diferente do Azure global.

Pode parecer:

  • 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 a configuração dos VMs, consulte executar uma Windows VM no Azure Stack Hub.

Rede virtual

Quando criar a rede virtual, determine quantos endereços IP os seus recursos em cada sub-rede requerem. Especifique uma máscara de sub-rede e um intervalo de endereços de rede suficientemente grande para os endereços IP necessários, utilizando a 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 portal de entrada entre a rede virtual e a rede no local mais tarde. Uma vez que cria 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, consulte Plano e design redes virtuais Azure.

Balanceadores de carga

Não exponha os VM diretamente à Internet, mas em vez disso dê a cada VM um endereço IP privado. Os clientes conectam-se utilizando o endereço IP público associado ao Balanceador de Carga camada 7.

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, mapear a porta 80 da configuração frontal para a porta 80 na piscina de endereços traseiros. 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 do cliente são distribuídos por todos os VMs na piscina de endereços 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 acima mostrada, o nível web não comunica diretamente com o nível da base de dados. Para impor esta regra, o nível de base de dados deve bloquear o tráfego de entrada a partir da sub-rede de nível web.

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

  2. Permitir o tráfego de entrada a partir da sub-rede de nível de negócio.

  3. Permitir o tráfego de entrada a partir da própria sub-rede de nível de base de dados. Esta regra permite a comunicação entre os VMs da base de dados, que é necessário para a replicação da base de dados e para a falha.

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

Crie regras 2 - 4 com maior prioridade do que a primeira regra, por isso substituem-na.

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 a camada VM alta disponibilidade, todos os VMs SQL devem estar em um 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 houver uma falha noutra réplica, o balançador 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 escrever, pode descarregar algumas das consultas apenas 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 SQL otimização de desempenho, também pode consultar o artigo SQL as melhores práticas do servidor para otimizar o desempenho no Azure Stack Hub.

Caixa de salto

Não permita o acesso do RDP da Internet pública aos VMs que executam a carga de trabalho da aplicação. Em vez disso, todo o acesso rdp a estes VMs deve passar pela caixa de salto. 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 caixa de salto tem requisitos mínimos de desempenho, por isso selecione um pequeno tamanho VM. Crie um endereço IP público para a jumpbox. Coloque a caixa de salto na mesma rede virtual que os outros VMs, mas numa sub-rede de gestão separada.

Para proteger a caixa de salto, adicione uma regra NSG que permite 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 níveis web e de negócio, considere usar conjuntos de escala de máquina virtual em vez de implantar VMs separados. Um conjunto de escala facilita a implantação e gestão de um conjunto de VMs idênticos. Considere os conjuntos de escala se precisar de escalar rapidamente os VMs.

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

  • Utilize extensões para configurar o VM depois de ser implantado. 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, consulte considerações de Design para conjuntos de escalas. Esta consideração de design é principalmente verdadeira para Azure Stack Hub, no entanto existem algumas ressalvas:

  • Os conjuntos de escala de máquina virtual no Azure Stack Hub não suportam atualizações de superprovisionamento ou de rolamento.

  • Não é possível escalar automaticamente os conjuntos de balanças 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 conjunto de escala de máquina virtual

  • Atualmente, existe um limite de 700 VM no Azure Stack Hub, que é responsável por todos os VMs de infraestrutura Azure Stack Hub, VMs individuais e instâncias definidas em escala.

Limites da subscrição

Cada subscrição de inquilinos Azure Stack Hub tem limites padrão em vigor, incluindo um número máximo de VMs por região configurado pelo operador Azure Stack Hub. Para mais informações, consulte os serviços do Azure Stack Hub, planos, ofertas, visão geral das subscrições. Consulte também os 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 padrão, os VMs numa rede virtual não podem 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. Criptografe dados sensíveis em repouso e use o 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 para armazenar segredos de aplicações, como cadeias de ligação de base de dados, em Key Vault.

Passos seguintes