IaaS: aplicativo Web com banco de dados relacional

Gateway de Aplicativo
Bastion
Load Balancer
Gerenciador de Tráfego

Essa solução fornece práticas recomendadas para aplicar zonas de disponibilidade a um aplicativo Web e Microsoft SQL Server banco de dados hospedado em VMs (máquinas virtuais).

Arquitetura

Diagrama de arquitetura que mostra máquinas virtuais que hospedam aplicativos Web e bancos de dados SQL Server e são distribuídas em três zonas.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de trabalho

A arquitetura usa recursos distribuídos em várias zonas para fornecer alta disponibilidade a um aplicativo Web IaaS (Infraestrutura como Serviço) que usa um banco de dados SQL Server. Uma instância com redundância de zona do Gateway de Aplicativo do Azure roteia o tráfego para VMs na camada da Web. Um balanceador de carga com redundância de zona roteia o tráfego das VMs na camada da Web para a instância de SQL Server ativa. Em caso de falha de zona, Gateway de Aplicativo rotas para VMs em outras zonas disponíveis. O roteamento entre zonas tem latência maior do que o roteamento dentro da zona.

Se a instância de SQL Server ativa ficar indisponível, seja devido a uma falha de zona ou a uma falha local, uma instância de SQL Server passiva se tornará ativa. O balanceador de carga com redundância de zona detecta o failover para a instância de SQL Server recém-ativa e roteia o tráfego para ela.

O diagrama a seguir ilustra uma falha da zona 1.

Diagrama de arquitetura que mostra uma falha na zona 1.

Baixe um Arquivo Visio dessa arquitetura.

A instância de Gateway de Aplicativo é com redundância de zona. Ele não é afetado pela falha da zona 1 e usa investigações de integridade para determinar as VMs disponíveis. Com a zona 1 indisponível, ele roteia o tráfego apenas para as duas zonas restantes. O balanceador de carga com redundância de zona também não é afetado pela falha da zona 1 e usa investigações de integridade para determinar o local da instância de SQL Server ativa. Neste exemplo, o balanceador de carga detecta que SQL Server está ativo na zona 3 e roteia o tráfego para ele.

A distribuição de recursos entre zonas de disponibilidade também protege um aplicativo contra manutenção planejada. Quando as VMs são distribuídas entre três zonas de disponibilidade, elas são, de fato, distribuídas entre três domínios de atualização. A plataforma do Azure reconhece essa distribuição entre domínios de atualização para garantir que as VMs em zonas diferentes não sejam atualizadas ao mesmo tempo.

Ao replicar VMs entre zonas de disponibilidade, você pode proteger seus aplicativos e dados contra uma falha de zona. É assim que o Azure atende ao SLA (contrato de nível de serviço) de tempo de atividade da VM melhor do setor. Para obter mais informações, consulte Criando soluções para alta disponibilidade usando zonas de disponibilidade.

Componentes

A arquitetura usa os seguintes componentes.

Geral

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

  • As zonas de disponibilidade são locais físicos separados em uma região do Azure, cada um com um ou mais datacenters que têm 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

  • A Rede Virtual do Azure é o bloco de construção fundamental das redes privadas no Azure. Cada VM do Azure é implantada em uma rede virtual que pode ser segmentada em sub-redes com uma sub-rede para cada camada.

  • Gateway de Aplicativo é um balanceador de carga de camada 7. Nessa arquitetura, uma instância de Gateway de Aplicativo com redundância de zona roteia solicitações HTTP para o front-end da Web. Gateway de Aplicativo também fornece Firewall de Aplicativo Web do Azure, que protege o aplicativo contra explorações e vulnerabilidades comuns. O SKU v2 do Gateway de Aplicativo dá suporte à redundância entre zonas. Uma única implantação de Gateway de Aplicativo pode executar várias instâncias de gateway. Para cargas de trabalho de produção, execute pelo menos duas. Para obter mais informações, consulte Dimensionamento automático e com redundância de zona Gateway de Aplicativo v2 e Como Gateway de Aplicativo dá suporte à alta disponibilidade e escalabilidade?.

  • Azure Load Balancer é um balanceador de carga de camada 4. Nessa arquitetura, um Standard Load Balancer do Azure com redundância de zona direciona o tráfego de rede da camada da Web para SQL Server. Como um balanceador de carga com redundância de zona não está fixado em uma zona específica, o aplicativo continua distribuindo o tráfego de rede durante uma falha de zona. Um balanceador de carga com redundância de zona é usado para fornecer disponibilidade quando a instância de SQL Server ativa fica indisponível. O SKU padrão de Load Balancer dá suporte à redundância entre zonas. Para mais informações, confira Standard Load Balancer e zonas de disponibilidade.

  • Os grupos de segurança de rede são usados para restringir o tráfego de rede em uma rede virtual. Nessa arquitetura, a camada da Web aceita apenas o tráfego do ponto de extremidade ip público. Além disso, a camada de banco de dados não aceita tráfego de nenhuma sub-rede que não seja a sub-rede da camada da Web.

  • A Proteção contra DDoS do Azure oferece recursos avançados de mitigação de DDoS (negação de serviço distribuído). A plataforma do Azure fornece proteção contra DDoS, mas a Proteção contra DDoS fornece proteção adicional. Para obter mais informações, confira Considerações de segurança.

  • O Azure Bastion fornece acesso seguro e contínuo do PROTOCOLO RDP e SSH (Secure Shell) às VMs em uma rede virtual. Esse serviço fornece acesso enquanto limita os endereços IP públicos expostos das VMs dentro da rede virtual. O Azure Bastion fornece uma alternativa econômica a uma VM provisionada para fornecer acesso a todas as VMs na mesma rede virtual.

SQL Server

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

  • O recurso Testemunha de Nuvem do SQL Server usa Armazenamento de Blobs do Azure para fornecer uma votação sobre o quorum do cluster. Um cluster de failover requer que mais da metade de seus nós estejam em execução, uma condição conhecida como quorum. Se o cluster tiver apenas dois nós, uma partição de rede poderá fazer com que cada nó pense que é o nó primário. 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 usa o Armazenamento de Blobs como um ponto de arbitragem. O Armazenamento de Blobs deve usar o armazenamento com redundância de zona para não ser afetado por uma falha de zona.

Detalhes do cenário

As zonas de disponibilidade do Azure são locais físicos separados em uma região do Azure, cada um com um ou mais datacenters que têm energia, resfriamento e rede independentes. A separação física das zonas de disponibilidade dentro de uma região limita o efeito de falhas de zona em aplicativos e dados. A arquitetura de referência apresentada neste artigo demonstra as melhores práticas para uma implantação zonal— uma implantação que usa zonas de disponibilidade para aumentar a disponibilidade do aplicativo. Uma implantação zonal é apropriada para muitos tipos de aplicativos. O exemplo específico mostrado aqui é a implantação zonal de um aplicativo Web que é executado em VMs (máquinas virtuais) e usa um banco de dados SQL Server.

Essa abordagem é usada em cenários de alta disponibilidade em que a resiliência é muito importante. Com a arquitetura de HA, há um equilíbrio entre alta resiliência, baixa latência e custo. Essa arquitetura usa recursos redundantes distribuídos entre zonas para fornecer alta resiliência. O tráfego pode ser roteado entre zonas para minimizar o impacto de uma falha de zona. Se uma zona falhar, os recursos em outras zonas absorverão o tráfego até que a zona com falha seja recuperada. Isso fornece um alto nível de resiliência.

Essa arquitetura fornece um uso eficiente de recursos, pois a maioria dos recursos são usados ativamente. Todos os recursos, além da instância de SQL Server passiva, são usados no tratamento de solicitações. A instância de SQL Server passiva ficará ativa somente se a instância ativa falhar.

A instância de Gateway de Aplicativo com redundância de zona e o balanceador de carga com redundância de zona distribuem o tráfego para os recursos disponíveis.

Recomendações

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

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

Para obter mais informações sobre como criar redes virtuais e sub-redes, confira Planejar e criar redes virtuais do Azure.

Grupos de segurança de rede

Use regras de grupo de segurança de rede para restringir o tráfego entre camadas. Nessa arquitetura, somente a camada da Web pode se comunicar diretamente com a camada de banco de dados. Para impor essa regra, a camada de banco de dados bloqueia todo o tráfego de entrada, exceto para a sub-rede da camada da Web.

  • Negue todo o tráfego de entrada da rede virtual. (Use a marca VIRTUAL_NETWORK na regra.)
  • Permitir o tráfego de entrada da sub-rede da camada da Web.
  • Permitir o tráfego de entrada da própria sub-rede da camada de banco 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.

Crie a segunda e a terceira regras com prioridade mais alta do que a primeira regra, para que elas a substituam.

Grupos de disponibilidade Always On do SQL Server

Recomendamos Always On grupos de disponibilidade para SQL Server alta 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 o grupo de disponibilidade SQL Server Always On da seguinte maneira:

  • Crie um cluster WSFC (Clustering de Failover do Windows Server), um grupo de disponibilidade SQL Server Always On e uma réplica primária. Para obter mais informações, consulte Introdução com Always On grupos de disponibilidade.
  • Crie um balanceador de carga interno com um endereço IP privado estático.
  • 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.
  • 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 roteia automaticamente novas solicitações para uma nova réplica primária. Para obter mais informações, consulte Configurar um balanceador de carga para um grupo de disponibilidade em máquinas virtuais do Azure que executam SQL Server.

Um failover fecha as conexões de cliente existentes. Depois que o failover for concluído, novas conexões serão roteada para a nova réplica primária.

Se o aplicativo ler significativamente mais do que grava, redirecione algumas das consultas somente leitura para uma réplica secundária. Confira Conectar-se a uma réplica somente leitura.

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

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Disponibilidade

As zonas de disponibilidade fornecem alta resiliência em uma única 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, confira Executar um aplicativo de N camadas em várias regiões do Azure 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 eastus -o table

O recurso de computação do Azure Conjuntos de Dimensionamento de Máquinas Virtuais usa automaticamente grupos de posicionamento, que atuam como um conjunto de disponibilidade implícito. Para saber mais sobre os grupos de posicionamento, confira Como trabalhar com os conjuntos de dimensionamento de máquinas virtuais grandes.

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.
  • Load Balancer pode investigar com 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 retorna a VM para o pool de back-end quando a VM fica 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 a 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, consulte estes recursos:

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

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

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

Conjuntos de Dimensionamento de Máquinas Virtuais

O recurso Conjuntos de Dimensionamento de Máquinas Virtuais está disponível em todos os tamanhos de VM do Windows. Você é cobrado apenas pelas VMs do Azure implantadas e por quaisquer recursos de infraestrutura subjacentes adicionais consumidos, como armazenamento e rede. Não há encargos incrementais para o serviço Conjuntos de Dimensionamento de Máquinas Virtuais.

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

SQL Server

Se você escolher SQL do Azure Banco de Dados, que é um mecanismo de banco de dados paaS (plataforma como serviço) totalmente gerenciado, poderá reduzir os custos porque não é necessário 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, consulte preços SQL do Azure.

Para obter opções de preços de VM do SQL Server, consulte Preços de VMs do SQL.

Load Balancer

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

Para obter mais informações, consulte a seção de custo em Estrutura de arquitetura do Azure.

Gateway de Aplicativo

Gateway de Aplicativo deve ser provisionado com o SKU v2 e pode abranger várias zonas de disponibilidade. Com o SKU v2, o modelo de preços é orientado pelo consumo e tem dois componentes: um preço fixo por hora e um custo baseado em consumo.

Para obter mais informações, consulte a seção de preços em Dimensionamento automático e com redundância de zona Gateway de Aplicativo v2.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar 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. No entanto, você pode conectar explicitamente redes virtuais usando o emparelhamento de rede virtual.

Restrição de tráfego

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

Rede de perímetro

Considere adicionar uma NVA (solução de virtualização de rede) para criar uma rede de perímetro, também conhecida como DMZ (zona desmilitarizada), 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, confira DMZ de rede entre o Azure e um datacenter local.

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 recomendamos que você armazene segredos do aplicativo, como cadeias de conexão de banco de dados, em Key Vault.

Proteção contra DDoS

A plataforma do Azure fornece a proteção contra DDoS básica por padrão. Essa proteção básica é destinada à proteção da infraestrutura do Azure. Embora a proteção básica contra DDoS esteja habilitada automaticamente, é recomendável usar a Proteção contra DDoS do Azure. A Proteção contra DDoS usa o ajuste adaptável, com base nos padrões de tráfego de rede do aplicativo, para detectar ameaças. Essa prática permite aplicar mitigações contra ataques de DDoS que podem passar despercebidos pelas políticas de DDoS em toda a infraestrutura. A Proteção contra DDoS 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.

Próximas etapas