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, utilizando SQL Server no Windows para o nível de dados.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de trabalho
A arquitetura é composta pelos seguintes componentes:
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.
Zonas de disponibilidade. As zonas de disponibilidade são locais físicos dentro de uma região de Azure. Cada zona é constituída por um ou mais datacenters com potência independente, arrefecimento e networking. Ao colocar VMs em zonas, a aplicação torna-se resistente a falhas dentro de uma zona.
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.
Gateway de aplicação. Gateway de Aplicação é um equilibrador de carga de camada 7. Nesta arquitetura, encaminha pedidos HTTP para a frente web. Gateway de Aplicação também fornece uma firewall de aplicação web (WAF) que protege a aplicação de explorações e vulnerabilidades comuns.
Equilibradores de carga. Utilize o Azure Balanceador de Carga Standard 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.
DDos Proteção. Embora a plataforma Azure forneça proteção básica contra ataques de negação de serviço distribuídos (DDoS), recomendamos a utilização de Proteção de Rede Azure DDoS, que tem funcionalidades de mitigação melhoradas do DDoS. Veja as considerações de segurança.
Azure DNS. O DNS do Azure é um serviço de alojamento para domínios DNS. Fornece resolução de nome usando a infraestrutura Microsoft Azure. Ao alojar os seus domínios no Azure, pode gerir os recursos DNS com as mesmas credenciais, APIs, ferramentas e faturação dos seus outros serviços do Azure.
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 a tecnologia Windows Server 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 (DS AD).
Testemunha de Nuvem. 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 tiver apenas dois nós, uma divisória de rede pode fazer com que cada nó pense que é o nó primário. 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 Armazenamento de Blobs do Azure. 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.
Jumpbox. Também denominada anfitrião de bastião. Tradicionalmente, um VM seguro na rede que os administradores usam para ligar aos outros 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 o tráfego do Protocolo de Ambiente de Trabalho Remoto (PDR). A Azure oferece a solução gerida Azure Bastion para responder a esta necessidade.
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 um VM do Windows em Azure.
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.
Gateway de Aplicação
Para obter informações sobre a configuração Gateway de Aplicação, consulte Gateway de Aplicação visão geral da configuração.
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 à Gateway de Aplicação.
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.
- Negar todo o tráfego de entrada da rede virtual. (Utilize a etiqueta
VIRTUAL_NETWORKna regra.) - Permitir o tráfego de entrada a partir da sub-rede de nível de negócio.
- 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.
- 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.
Criar 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.
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:
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).
Crie um balanceador de carga interno com um endereço IP privado estático.
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.
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 significativamente 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.
Jumpbox
Quando se executam máquinas virtuais numa rede virtual privada, como nesta arquitetura, há necessidade de aceder a máquinas virtuais para instalação de software, patching, e assim por diante. Mas tornar estas máquinas acessíveis à internet pública não é uma boa ideia porque aumenta significativamente a superfície de ataque. Em vez disso, uma caixa de salto é usada como uma camada de acesso médio.
No passado, um VM que é gerido pelo cliente pode ser usado como uma caixa de salto. Nesse cenário, aplicam-se as seguintes recomendações:
- 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 entra na caixa de salto e depois entra na outra VM da caixa de salto. A caixa de salto permite o tráfego RDP a partir 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.
Para um VM gerido pelo cliente, todas estas regras se aplicam. No entanto, a recomendação atual é utilizar o Azure Bastion, uma solução de jumpbox gerida que permite o acesso do HTML5 a RDP ou SSH por trás Azure AD proteção. Esta é uma solução muito mais simples que, em última análise, tem um custo total mais baixo de propriedade (TCO) para o cliente.
Considerações
Escalabilidade
Conjuntos de dimensionamento
Para os níveis web e de negócio, considere usar Conjuntos de Dimensionamento de Máquinas Virtuais em vez de implementar VMs separados. Um conjunto de escala facilita a implantação e gestão de um conjunto de VMs idênticos e a autoescala os VMs com base em métricas de desempenho. À medida que a carga nas VMs aumenta, são adicionadas automaticamente VMs adicionais ao balanceador de carga. Considere os conjuntos de dimensionamento caso precise de aumentar horizontalmente e de forma rápida as VMs ou realizar um dimensionamento automático.
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 escala.
Dica
Quando utilizar uma solução de dimensionamento automático, teste-a com cargas de trabalho ao nível de produção com alguma antecedência.
Limites da subscrição
Cada subscrição do Azure tem limites predefinidos implementados, incluindo um número máximo de VMs por região. Pode aumentar o limite através do preenchimento de um pedido de suporte. Para obter mais informações, veja Subscrição do Azure e limites de serviço, quotas e restrições.
Gateway de Aplicação
Gateway de Aplicação suporta o modo de capacidade fixa ou o modo de autoscalagem. O modo de capacidade fixa é útil para cenários com cargas de trabalho consistentes e previsíveis. Considere utilizar o modo de autoescalagem para cargas de trabalho com tráfego variável. Para mais informações, consulte Autoscaling e Gateway de Aplicação redundante de zona v2
Disponibilidade
As zonas de disponibilidade proporcionam a melhor resiliência dentro de uma única região. Se precisar de uma disponibilidade ainda maior, considere replicar a aplicação em duas regiões, utilizando o Azure Traffic Manager para o failover. Para obter mais informações, consulte a aplicação multi-região N para obter uma elevada disponibilidade.
Nem todas as regiões suportam zonas de disponibilidade, e nem todos os tamanhos de VM são suportados em todas as zonas. Executar o seguinte comando Azure CLI para encontrar as zonas suportadas para cada tamanho VM dentro de 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 esta arquitetura para uma região que não suporta zonas de disponibilidade, coloque os VMs para cada nível dentro de um conjunto de disponibilidade. Os VMs dentro do mesmo conjunto de disponibilidade são implantados em vários servidores físicos, racks de computação, unidades de armazenamento e interruptores de rede para redundância. Os conjuntos de escala utilizam automaticamente grupos de colocação, que funcionam como um conjunto de disponibilidade implícita.
Ao implementar para zonas de disponibilidade, utilize o SKU Standard de Balanceador de Carga do Azure e o V2 SKU de Gateway de Aplicação. Estes SKUs apoiam a redundância de zonas cruzadas. Para obter mais informações, consulte:
- Balanceador de Carga Standard e Zonas de Disponibilidade
- Gateway de Aplicação com dimensionamento automático e redundância entre zonas v2
- Como é que Gateway de Aplicação suporta alta disponibilidade e escalabilidade?
Uma única Gateway de Aplicação implantação pode executar várias instâncias do gateway. Para cargas de trabalho de produção, executar pelo menos duas instâncias.
Sondas do estado de funcionamento
Gateway de Aplicação e Balanceador de Carga ambos usam sondas de saúde para monitorizar a disponibilidade de instâncias em VM.
- Gateway de Aplicação usa sempre uma sonda HTTP.
- Balanceador de Carga pode testar HTTP ou TCP. Geralmente, se um VM executa um servidor HTTP, utilize uma sonda HTTP. Caso contrário, utilize O TCP.
Se uma sonda não conseguir chegar a um caso dentro de um período de tempo, o gateway ou o equilibrador de carga para de enviar tráfego para esse VM. A sonda continua a verificar e devolverá o VM à piscina traseira se o VM voltar a estar disponível.
As sondas HTTP ENVIAM um pedido HTTP GET para um caminho especificado e ouvem uma resposta HTTP 200. Este caminho pode ser o caminho raiz ("/"), ou um ponto final de monitorização da saúde que implementa alguma lógica personalizada para verificar a saúde da aplicação. O ponto final tem de permitir pedidos HTTP anónimos.
Para obter mais informações sobre as sondas de saúde, consulte:
- Sondas de estado de funcionamento do Balanceador de Carga
- Visão geral da monitorização da saúde Gateway de Aplicação
Para obter considerações sobre a conceção de um ponto final da sonda de saúde, consulte o padrão de monitorização do ponto de saúde.
Otimização de custos
Utilize a Calculadora de Preços Azure para estimar os custos. Aqui estão outras considerações.
Conjuntos de dimensionamento de máquinas virtuais
Os conjuntos de escala de máquina virtual estão disponíveis em todos os tamanhos do Windows VM. Você é cobrado apenas para os VMs Azure que você implanta e quaisquer recursos adicionais subjacentes de infraestrutura consumidos, tais como armazenamento e networking. Não há encargos incrementais para o serviço Conjuntos de Dimensionamento de Máquinas Virtuais.
Para opções de preços individuais VMs Consulte os preços do Windows VMs
Servidor SQL
Se escolher SQL do Azure DBaas, pode economizar a custo porque não precisa de configurar um Grupo Sempre Disponível e máquinas de controlador de domínio. Existem várias opções de implementação a partir de uma única base de dados até casos geridos, ou piscinas elásticas. Para mais informações consulte SQL do Azure preços.
Para opções de preços de VMs de servidor SQL ver preços DE VMs SQL.
Balanceadores de carga
É cobrado apenas pelo número de regras configuradas de equilíbrio de carga e saída. As regras da NAT de entrada são gratuitas. Não há taxa de hora a hora para o Balanceador de Carga Standard quando não há regras configuradas.
Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.
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. No entanto, pode ligar explicitamente redes virtuais utilizando o espreitamento de rede virtual.
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.
A 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. Para obter mais informações, veja Implementar uma rede de perímetro entre o Azure e a Internet.
A encriptação. Encripte os dados confidenciais inativos e utilize o Azure Key Vault para gerir as chaves de encriptação da base de dados. O Key Vault pode armazenar chaves de encriptação nos módulos de segurança de hardware (HSMs). 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.
Proteção DDoS. A plataforma Azure fornece uma proteção DDoS básica por padrão. Esta proteção básica destina-se a proteger a infraestrutura Azure no seu conjunto. Embora a proteção básica do DDoS esteja ativada automaticamente, recomendamos a utilização da Proteção da Rede Azure DDoS. A Proteção de Rede utiliza sintonização adaptativa, com base nos padrões de tráfego de rede da sua aplicação, para detetar ameaças. Isto permite-lhe aplicar mitigações contra ataques DDoS que podem passar despercebidos pelas políticas de DDoS em toda a infraestrutura. A Proteção de Rede também fornece alerta, telemetria e análise através do Azure Monitor. Para mais informações, consulte Azure DDoS Protection: Melhores práticas e arquiteturas de referência.
Excelência operacional
Uma vez que todos os recursos principais e suas dependências estão na mesma rede virtual nesta arquitetura, eles estão isolados na mesma carga de trabalho básica. Esse facto facilita a associação dos recursos específicos da carga de trabalho a uma equipa, para que a equipa possa gerir de forma independente todos os aspetos desses recursos. Este isolamento permite que os DevOps realizem uma integração contínua e uma entrega contínua (CI/CD).
Além disso, pode utilizar diferentes modelos de implementação e integrá-los com os Serviços Azure DevOps para fornecer diferentes ambientes em minutos, por exemplo para replicar a produção como cenários ou ambientes de teste de carga apenas quando necessário, economizando custos.
Neste cenário, as suas máquinas virtuais são configuradas utilizando Extensões de Máquina Virtual, uma vez que oferecem a possibilidade de instalar determinado software adicional, como é o caso de anti malware e agentes de segurança. As extensões VM são instaladas e executadas apenas no tempo de criação de VM. Isto significa que, se o Sistema Operativo for configurado incorretamente numa fase posterior, será necessária uma intervenção manual para o transferir de volta para o seu estado correto.
As Ferramentas de Gestão de Configuração, em particular Desired State Configuration (DSC), são utilizadas nesta arquitetura para configurar o Ative Directory e um grupo de SQL Server Always On Availability.
Considere utilizar o Azure Monitor para analisar e otimizar o desempenho da sua infraestrutura, monitorizar e diagnosticar problemas de rede sem iniciar sessão nas suas máquinas virtuais. Application Insights é na verdade um dos componentes do Azure Monitor, que lhe dá métricas e registos ricos para verificar o estado da sua paisagem completa do Azure. O Azure Monitor irá ajudá-lo a seguir o estado da sua infraestrutura.
Certifique-se não só de monitorizar os elementos computativos que suportam o seu código de aplicação, mas também da sua plataforma de dados, em particular das suas bases de dados, uma vez que um baixo desempenho do nível de dados de uma aplicação pode ter consequências graves.
Para testar o ambiente Azure onde as aplicações estão em execução, deve ser controlado pela versão e implementado através dos mesmos mecanismos que o código de aplicação, então pode ser testado e validado usando paradigmas de teste de DevOps também.
Para mais informações, consulte a secção de Excelência Operacional no Quadro Well-Architected Azure.