Aplicativo de N camadas do Windows no Azure

Armazenamento de Blobs
DNS
Load Balancer
Rede Virtual
Máquinas Virtuais

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

Arquitetura de N camadas usando o Microsoft Azure

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho

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.

  • Zonas de disponibilidades. As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes. Ao colocar VMs entre zonas, o aplicativo se torna resiliente a falhas dentro de uma zona.

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.

  • Gateway de aplicativo. O Gateway de Aplicativo é um balanceador de carga da camada 7. Nessa arquitetura, ele roteia as solicitações HTTP para o front-end da web. Gateway de Aplicativo também fornece um firewall do aplicativo Web (WAF) que protege o aplicativo contra vulnerabilidades e explorações comuns.

  • Balanceadores de carga. Use o Azure Standard Load Balancer para distribuir o tráfego de rede da camada da Web para a camada empresarial e desta para o 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.

  • Proteção contra DDoS. Embora a plataforma do Azure forneça proteção básica em relação a ataques de negação de serviço distribuído (DDoS), é recomendável usar Proteção contra DDoS Standard, que melhorou os recursos de mitigação de DDoS. Consulte as considerações de segurança.

  • DNS do Azure. O DNS do Azure é um serviço de hospedagem para domínios DNS. Ele fornece resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure.

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

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

  • Jumpbox. Também chamada de um host bastião. Tipicamente, esta é uma VM segura 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 por protocolo RDP. O Azure oferece a solução gerenciada Azure Bastion para atender a essa necessidade.

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, confira Executar uma VM do Windows no Azure.

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.

Gateway de Aplicativo

Para obter informações sobre como configurar Gateway de Aplicativo, confira Visão geral da configuração do Gateway de Aplicativo.

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 com o Gateway de Aplicativo.

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.

Criar regras de 2 a 4 com prioridade mais alta 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.

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 realiza muito mais leituras do que gravações, você pode descarregar algumas das consultas somente leitura para 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.

Jumpbox

Quando você executa máquinas virtuais em uma rede virtual privada, como nessa arquitetura, há a necessidade de acessar máquinas virtuais para instalação de software, aplicação de patch e assim por diante. No entanto, tornar essas máquinas virtuais acessíveis para a Internet pública não é uma boa ideia, porque aumenta significativamente a superfície de ataque. Em vez disso, um jumpbox é usado como uma camada de acesso intermediário.

No passado, uma VM gerenciada pelo cliente poderia ser usada como um jumpbox. Nesse cenário, as seguintes recomendações se aplicam:

  • 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, depois, faz logon na VM por meio do jumpbox. O jumpbox permite 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.

Para uma VM gerenciada pelo cliente, todas essas regras se aplicam. No entanto, a recomendação atual é usar o Azure Bastion, uma solução gerenciada de jumpbox que permite acesso HTML5 a RDP ou SSH por trás da proteção Azure AD. Essa é uma solução muito mais simples que, em última análise, tem um TCO (custo total de propriedade) menor para o cliente.

Considerações

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 gerenciamento de um conjunto de VMs idênticas e o dimensionamento automático de VMs com base em métricas de desempenho. À medida que a carga nas VMs aumenta, VMs adicionais são acrescentadas automaticamente ao balanceador de carga. Considere usar os conjuntos de dimensionamento se você precisar aumentar as VMs rapidamente ou se precisar de dimensionamento automático.

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.

Dica

Ao usar qualquer solução de dimensionamento automático, teste-a com cargas de trabalho no nível de produção com bastante antecedência.

Limites de assinatura

Cada assinatura do Azure tem limites padrão em vigor, incluindo um número máximo de VMs por região. Você pode aumentar o limite enviando uma solicitação de suporte. Para saber mais, confira Assinatura e limites de serviço, cotas e restrições do Azure.

Gateway de Aplicativo

O Gateway de Aplicativo dá suporte ao modo de capacidade fixa ou ao modo de dimensionamento automático. O modo de capacidade fixa é útil para cenários com cargas de trabalho consistentes e previsíveis. Considere usar o modo de dimensionamento automático para cargas de trabalho com tráfego variável. Para obter mais informações, confira Dimensionamento automático e Gateway de Aplicativo com redundância de zona v2

Disponibilidade

As zonas de disponibilidade fornecem a melhor resiliência ao replicar em apenas uma região. Se você precisar de disponibilidade mais alta, replique o aplicativo em duas regiões e use o Gerenciador de Tráfego do Azure para failover. Para obter mais informações, consulte Aplicativo de N camadas de várias regiões para alta disponibilidade.

Nem todas as regiões dão suporte a zonas de disponibilidade e nem todos os tamanhos de VM são compatíveis com todas as zonas. Execute o seguinte comando da CLI do Azure para localizar as zonas compatíveis com cada tamanho de VM em uma região:

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

Se você implantar essa arquitetura em uma região que não dá suporte a zonas de disponibilidade, coloque as VMs para cada camada em um conjunto de disponibilidade. As VMs no mesmo conjunto de disponibilidade são implantadas em vários servidores físicos, racks de computação, unidades de armazenamento e comutadores de rede para redundância. Os conjuntos de dimensionamento automaticamente usam grupos de posicionamento, que funcionam como um conjunto de disponibilidade implícito.

Ao implantar em zonas de disponibilidade, use o SKU Standard do Azure Load Balancer e o SKU v2 do Gateway de Aplicativo. Esses SKUs dão suporte à redundância entre zonas. Para obter mais informações, consulte:

Uma implantação do Gateway de Aplicativo pode executar várias instâncias do gateway. Para cargas de trabalho de produção, execute pelo menos duas instâncias.

Investigações de integridade

O Gateway de Aplicativo e o Load Balancer usam investigações de integridade para monitorar a disponibilidade de instâncias de VM.

  • O Gateway de Aplicativo sempre usa uma investigação HTTP.
  • O Load Balancer pode testar HTTP ou TCP. Em geral, se uma VM executar um servidor HTTP, use uma investigação HTTP. Caso contrário, use TCP.

Se uma investigação não puder acessar uma instância dentro de um período de tempo limite, o gateway ou balanceador de carga deixará de enviar tráfego para essa VM. A investigação continua a verificar e retornará a VM para o pool de back-end se a VM ficar disponível novamente.

As investigações HTTP enviam uma solicitação HTTP GET para um caminho especificado e escutam uma resposta HTTP 200. Esse caminho pode ser o caminho raiz (“/”) ou um ponto de extremidade de monitoramento de integridade que implementa lógica personalizada para verificar a integridade do aplicativo. O ponto de extremidade deve permitir solicitações HTTP anônimas.

Para obter mais informações sobre investigações de integridade, confira:

Para obter considerações sobre como criar um ponto de extremidade de investigação de integridade, confira Padrão de Monitoramento de Ponto de Extremidade de Integridade.

Otimização de custo

Use a Calculadora de Preços do Azure para estimar os custos. Algumas outras considerações.

conjuntos de escala de máquina virtual

Os conjuntos de dimensionamento de máquinas virtuais estão disponíveis em todos os tamanhos de VM do Windows. Você só é cobrado pelas VMs do Azure implantadas e pelos recursos adicionais de infraestrutura subjacentes consumidos, como armazenamento e rede. Não há cobranças incrementais para o serviço de conjuntos de dimensionamento de máquinas virtuais.

Para obter opções de preços de VMs simples, confira os preços das VMs do Windows

SQL Server

Se você escolher DBaas do SQL do Azure, poderá economizar porque não precisará configurar um grupo de disponibilidade Always On e computadores do controlador de domínio. Há várias opções de implantação, de banco de dados individual a instância gerenciada ou pools elásticos. Para obter mais informações, confira os Preços de SQL do Azure.

Para opções de preços de VMs do SQL Server, confira os Preços das VMs de SQL.

Balanceadores de carga

Você é cobrado apenas pelo número de regras de balanceamento de carga e de saída configuradas. As regras NAT de entrada são gratuitas. Não há cobrança por hora para o Standard Load Balancer quando nenhuma regra é configurada.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

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. No entanto, você pode conectar explicitamente redes virtuais usando o emparelhamento de rede virtual.

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. Para obter mais informações, consulte Implementação de uma DMZ entre o Azure e a Internet.

Criptografia. Criptografe dados confidenciais em repouso e use o Azure Key Vault para gerenciar as chaves de criptografia de banco de dados. O Key Vault pode armazenar chaves de criptografia em HSMs (módulos de segurança de hardware). 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.

Proteção contra DDoS. A plataforma do Azure fornece a proteção contra DDoS básica por padrão. Essa proteção básica se destina a proteger a infraestrutura do Azure como um todo. Embora a proteção contra DDoS básica esteja habilitada automaticamente, é recomendável usar a Proteção contra DDoS Standard. A proteção Standard utiliza ajuste adaptável, com base nos padrões de tráfego de rede do seu aplicativo, para detectar ameaças. Isso permite aplicar mitigações de risco contra ataques de DDoS que podem não ser detectadas pelas políticas de DDoS de toda a infraestrutura. A proteção Standard também fornece alertas, telemetria e análise por meio do Azure Monitor. Para obter mais informações, confira Proteção contra DDoS do Azure: práticas recomendadas e arquiteturas de referência.

Excelência operacional

Como todos os recursos principais e suas dependências estão na mesma rede virtual nessa arquitetura, eles são isolados na mesma carga de trabalho básica. Esse fato torna mais fácil associar os recursos específicos da carga de trabalho a uma equipe, para que a equipe possa gerenciar independentemente todos os aspectos desses recursos. Esse isolamento permite que o DevOps execute a CI/CD (integração contínua e entrega contínua).

Você também pode usar modelos de implantação diferentes e integrá-los ao Azure DevOps Services para provisionar ambientes diferentes em minutos, por exemplo, para replicar cenários semelhantes à produção ou ambientes de teste de carga somente quando necessário, economizando custos.

Nesse cenário, suas máquinas virtuais são configuradas usando extensões de máquina virtual, pois oferecem a possibilidade de instalar determinados softwares adicionais, como anti malware e agentes de segurança. As Extensões de VM são instaladas e executadas somente no momento da criação da VM. Isso significa que, se o sistema operacional for configurado incorretamente em uma fase posterior, ele exigirá uma intervenção manual para retorná-lo ao estado correto.

As Ferramentas de Gerenciamento de Configuração, em particular DSC (Desired State Configuration), são usadas nessa arquitetura para configurar o Active Directory e um grupo de disponibilidade Always On do SQL Server.

Considere usar o Azure Monitor para analisar e otimizar o desempenho de sua infraestrutura e monitorar e diagnosticar problemas de rede sem fazer logon em suas máquinas virtuais. O Application Insights é um dos componentes do Azure Monitor, que fornece métricas e logs avançados para verificar o estado de seu cenário completo do Azure. O Azure Monitor ajudará você a seguir o estado da infraestrutura.

Certifique-se de monitorar não somente os elementos de computação que dão suporte ao código do aplicativo, mas também à plataforma de dados, especialmente seus bancos de dados, pois o mau desempenho da camada de dados de um aplicativo pode ter consequências sérias.

Para testar o ambiente do Azure no qual os aplicativos estão em execução, ele deve ser controlado por versão e implantado por meio dos mesmos mecanismos que o código do aplicativo e, portanto, também pode ser testado e validado usando os paradigmas de teste de DevOps.

Para obter mais informações, confira a seção Excelência Operacional no Azure Well-Architected Framework.

Próximas etapas