Editar

Compartilhar via

Aplicativo de N camadas com Apache Cassandra

DNS do Azure
Azure Load Balancer
Azure Monitor
Máquinas Virtuais do Azure
Rede Virtual do Azure

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 Apache Cassandra no Linux para a camada de dados.

Arquitetura

Diagrama que mostra a arquitetura de N camadas que usa o Microsoft Azure.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

A arquitetura tem os seguintes componentes.

Geral

  • Grupo de recursos. Grupos de recursos são utilizados para agrupar os recursos do Azure para que eles possam ser gerenciados pelo tempo de vida, pelo proprietário ou por outros critérios.

  • Zonas de disponibilidades. As zonas de disponibilidade são localizações físicas exclusivas 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 comercial.

  • 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 contra ataques de DDoS (negação de serviço distribuído), recomendamos o uso da Proteção de Rede contra DDoS do Azure, que aprimorou os recursos de mitigação de DDoS. Confira 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

  • Banco de dados Apache Cassandra. Fornece alta disponibilidade na camada de dados, habilitando replicação e failover.

  • OpsCenter. Implante uma solução de monitoramento, como o DataStax OpsCenter, para monitorar o cluster Cassandra.

  • Jump box. 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 executar o tráfego remoto somente de endereços IP públicos em uma lista segura. O NSG deve permitir o tráfego por protocolo RDP.

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 Linux 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 (roteamento entre domínios sem classificação). 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 VNets e sub-redes, consulte Planejar e criar redes virtuais do Azure.

Gateway de Aplicativo

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

Balanceadores de carga

Não exponha as VMs diretamente à Internet. Em vez disso, dê um endereço IP privado a cada VM. Os clientes se conectam usando o endereço IP 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, crie uma regra que 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.

Grupos de segurança de rede

Use as regras de NSG para restringir o tráfego entre as camadas. Por exemplo, 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 isso, 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 SSH (porta 22) 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.

Cassandra

Recomendamos o DataStax Enterprise para uso de produção, mas essas recomendações se aplicam a qualquer edição do Cassandra. Para obter mais informações sobre como executar o DataStax no Azure, consulte Guia de implantação do DataStax Enterprise no Azure.

Configure os nós no modo de reconhecimento de rack. Mapear domínios de falha para racks no arquivo cassandra-rackdc.properties.

Não é necessário um balanceador de carga na frente do cluster. O cliente se conecta diretamente a um nó no cluster.

Os scripts de implantação dessa arquitetura usam a resolução de nomes para inicializar o nó de semente para comunicação intracluster (gossip). Para habilitar a resolução de nomes, a implantação cria uma zona de DNS Privado do Azure com registros A para os nós do Cassandra. Dependendo dos scripts de inicialização, talvez você possa usar o endereço IP estático em vez disso.

Observação

No momento, o DNS privado do Azure está em versão prévia pública.

Jumpbox

Não permita o acesso SSH da Internet pública para as VMs que executam a carga de trabalho do aplicativo. Em vez disso, todo o acesso SSH a essas VMs deve ocorrer por meio do jumpbox. Um administrador faz logon no jumpbox e, em seguida, faz logon na VM por meio do jumpbox. O jumpbox permite que tráfego SSH 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 SSH somente de um conjunto seguro de endereços IP públicos. Configure os NSGs para outras sub-redes para permitir o tráfego SSH da sub-rede de gerenciamento.

Considerações

Escalabilidade

Conjuntos de dimensionamento

Para as camadas Web e business, considere o uso de Conjuntos de Dimensionamento de Máquinas Virtuais, em vez de implantar VMs separadas em um conjunto de disponibilidade. 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.

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 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 o Gateway de Aplicativo com redundância de zona v2.

Eficiência de desempenho

Para obter o melhor desempenho do Cassandra em VMs do Azure, confira as recomendações em Executar Apache Cassandra em VMs do Azure.

Disponibilidade

As zonas de disponibilidade fornecem a melhor resiliência ao replicar em apenas uma região. Se você precisar de disponibilidade ainda maior, considere replicar o aplicativo em duas regiões.

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 dentro da mesma 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 saber mais, veja:

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

Cluster do Cassandra

Para o cluster Cassandra, os cenários de failover dependem dos níveis de consistência usados pelo aplicativo e do número de réplicas. Para obter níveis de consistência e uso no Cassandra, confira Configurar a consistência de dados e Cassandra: com quantos nós é possível conversar com o Quorum? A disponibilidade de dados no Cassandra é determinada pelo nível de consistência usado pelo aplicativo e pelo mecanismo de replicação. Para replicação no Cassandra, consulte Explicação de replicação de dados em Bancos de Dados NoSQL.

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 do tempo limite, o gateway ou o 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. Confira outras considerações.

Conjuntos de dimensionamento de máquinas virtuais

Os conjuntos de dimensionamento de máquinas virtuais estão disponíveis em todos os tamanhos de VM do Linux. Você só é cobrado pelas VMs do Azure implantadas e pelos recursos de infraestrutura subjacentes consumidos, como armazenamento e rede. O serviço Conjuntos de Dimensionamento de Máquina Virtual por si só não incorre em nenhum encargo adicional.

Para opções de preço de VMs individuais, confira os preços de VMs do Windows.

Balanceadores de carga

Você é cobrado apenas pelo número de regras de balanceamento de carga e de saída configuradas. As regras NAT (conversão de endereços de rede) de entrada são gratuitas. Não há cobrança por hora para o Standard Load Balancer quando nenhuma regra está 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. As VMs de uma rede virtual não podem se comunicar diretamente com as VMs de outra rede virtual. As VMs na mesma rede virtual podem se comunicar, a menos que você crie NSGs (Grupos de Segurança de Rede) para restringir o tráfego. Para obter mais informações, consulte Serviços em nuvem da Microsoft e segurança de rede.

Para tráfego de entrada da Internet, as regras do balanceador de carga definem qual tráfego pode alcançar o back-end. No entanto, as regras do balanceador de carga não dão suporte a listas de IP de confiança, por isso se você desejar adicionar determinados endereços IP públicos a uma lista de confiança, acrescente um NSG à sub-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). 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 de Rede contra DDoS do Azure. A Proteção de Rede usa 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 de Rede 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 facilita a associação dos recursos específicos da carga de trabalho a uma equipe de DevOps, para que a equipe possa gerenciar de maneira independente todos os aspectos desses recursos. Esse isolamento permite que o DevOps Teams e Services executem 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 carregar ambientes de teste de carga somente quando necessário, economizando custos.

Nesse cenário, as máquinas virtuais são configuradas usando extensões de máquina virtual, pois oferecem a possibilidade de instalar determinados softwares adicionais, como o Apache Cassandra. Em particular, a Extensão de Script Personalizado permite o download e a execução de código arbitrário em uma Máquina Virtual, permitindo a personalização ilimitada do Sistema Operacional de uma VM do Azure. 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 um estágio posterior, ele exigirá uma intervenção manual para movê-lo de volta para o estado correto. As Ferramentas de Gerenciamento de Configuração podem ser usadas para resolver esse problema.

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.

Monitore não somente os elementos de computação que dão suporte ao código do aplicativo, mas também a plataforma de dados, especialmente os 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 em Microsoft Azure Well-Architected Framework.

Próximas etapas