Esta arquitetura de referência mostra como implantar máquinas virtuais (VMs) e uma rede virtual configurada para um aplicativo de N camadas , usando Apache Cassandra no Linux para a camada 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 usados para agrupar recursos do Azure para que possam ser gerenciados por tempo de vida, proprietário ou outros critérios.
Zonas de disponibilidade. As zonas de disponibilidade são locais físicos dentro de uma região do Azure. Cada zona consiste em um ou mais datacenters com alimentação, resfriamento e rede independentes. Ao colocar VMs entre zonas, o aplicativo se torna resiliente a falhas dentro de uma zona.
Rede e balanceamento de carga
Rede virtual e sub-redes. Cada VM do Azure é implantada em uma rede virtual que pode ser segmentada em sub-redes. Crie uma sub-rede separada para cada camada.
Gateway de aplicativo. O Application Gateway é um balanceador de carga de camada 7. Nessa arquitetura, ele roteia solicitações HTTP para o front-end da Web. O Application Gateway também fornece um firewall de aplicativo Web (WAF) que protege o aplicativo contra exploits e vulnerabilidades comuns.
Balanceadores de carga. Use o Balanceador de Carga Padrão do Azure para distribuir o tráfego de rede da camada da Web para a camada comercial.
Grupos de segurança de rede (NSGs). Use NSGs para restringir o tráfego de rede dentro da rede virtual. Por exemplo, na arquitetura de três camadas mostrada aqui, a camada de banco de dados não aceita tráfego do front-end da Web, apenas da camada de negócios e da sub-rede de gerenciamento.
Proteção contra DDoS. Embora a plataforma Azure forneça proteção básica contra ataques distribuídos de negação de serviço (DDoS), recomendamos o uso da Proteção de Rede DDoS do Azure, que aprimorou 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 alojamento para domínios DNS. Ele fornece resolução de nomes usando a infraestrutura do 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
Base de dados do Apache Cassandra. Fornece uma elevada disponibilidade na camada de dados ao ativar a replicação e a ativação pós-falha.
Centro Operacional. Implante uma solução de monitoramento, como o DataStax OpsCenter , para monitorar o cluster Cassandra.
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 como configurar as VMs, consulte Executar uma VM Linux no Azure.
Rede virtual
Ao 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 . 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 local, caso precise configurar um gateway entre a VNet e sua rede local mais tarde. Depois de criar a VNet, 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 criação de VNets e sub-redes, veja Planear e estruturar as Redes Virtuais do Azure.
Gateway de Aplicação
Para obter informações sobre como configurar o Application Gateway, consulte Visão geral da configuração do Application Gateway.
Balanceadores de carga
Não exponha as VMs diretamente à Internet. Em vez disso, forneça a cada VM um endereço IP privado. Os clientes se conectam usando o endereço IP associado ao Application Gateway.
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, crie uma regra para mapear a porta 80 da configuração de front-end para a porta 80 no conjunto de endereços de back-end. 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. As solicitações de cliente são distribuídas em todas as VMs.
Grupos de segurança de rede
Utilize as regras do 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 esta regra, a camada da base de dados deve bloquear o tráfego de entrada da sub-rede da camada Web.
- Negar todo o tráfego de entrada da rede virtual. (Utilize a etiqueta
VIRTUAL_NETWORKna regra.) - Permitir tráfego de entrada da sub-rede da camada de negócios.
- Permita o tráfego de entrada da própria sub-rede da camada de banco de dados. Esta regra permite a comunicação entre as VMs de banco de dados, que é necessária para replicação e failover de banco de dados.
- Permitir tráfego ssh (porta 22) a partir da sub-rede jumpbox. Esta regra permite aos administradores estabelecer ligação com o escalão da base de dados a partir da jumpbox.
Crie regras 2 a 4 com prioridade maior do que a primeira regra, para que elas a substituam.
Cassandra
Recomendamos o DataStax Enterprise para a produção, mas estas recomendações aplicam-se a qualquer edição do Cassandra. Para obter mais informações sobre a execução do DataStax no Azure, veja DataStax Enterprise Deployment Guide for Azure (Guia de Implementação do DataStax no Azure).
Configure nós no modo de deteção de bastidores. Mapeie os domínios de falha para os bastidores no ficheiro cassandra-rackdc.properties.
Não precisa de um balanceador de carga à frente do cluster. O cliente liga-se diretamente a um nó no cluster.
Os scripts de implantação para essa arquitetura usam a resolução de nomes para inicializar o nó semente para comunicação intra-cluster (fofoca). Para habilitar a resolução de nomes, a implantação cria uma zona DNS Privada do Azure com registros A para os nós Cassandra. Dependendo dos scripts de inicialização, você poderá usar o endereço IP estático.
Nota
O DNS Privado do Azure está atualmente em pré-visualização pública.
Jumpbox
Não permita o acesso ssh da Internet pública às VMs que executam a carga de trabalho do aplicativo. Em vez disso, todo o acesso ssh a essas VMs deve vir através da jumpbox. Um administrador inicia sessão na jumpbox e, em seguida, inicia sessão noutra VM a partir da jumpbox. O jumpbox permite o tráfego ssh da Internet, mas apenas a partir de endereços IP conhecidos e seguros.
O jumpbox tem requisitos mínimos de desempenho, portanto, selecione um tamanho de VM pequeno. Crie um endereço IP público para a jumpbox. Coloque a jumpbox na mesma VNet que as outras VMs, mas numa sub-rede de gestão separada.
Para proteger a jumpbox, adicione uma regra NSG que permita conexões ssh somente de um conjunto seguro de endereços IP públicos. Configure os NSGs para as outras sub-redes para permitir o tráfego ssh da sub-rede de gerenciamento.
Considerações
Escalabilidade
Conjuntos de dimensionamento
Para as camadas da Web e de negócios, considere o uso de Conjuntos de Dimensionamento de Máquina Virtual, em vez de implantar VMs separadas em um conjunto de disponibilidade. Um conjunto de dimensionamento facilita a implantação e o gerenciamento de um conjunto de VMs idênticas e o dimensionamento automático das 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.
Existem duas formas básicas de configurar as VMs implementadas num conjunto de dimensionamento:
Use extensões para configurar a VM depois que ela for implantada. 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.
Gorjeta
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, quotas e restrições do serviço.
Gateway de Aplicação
O Application Gateway suporta o modo de capacidade fixa ou o modo de dimensionamento automático. O modo de capacidade fixa é útil para cenários com cargas de trabalho consistentes e previsíveis. Considere o uso do modo de dimensionamento automático para cargas de trabalho com tráfego variável. Para obter mais informações, consulte Autoscaling and Zone-redundant Application Gateway v2.
Eficiência de desempenho
Para obter o melhor desempenho do Cassandra em VMs do Azure, consulte as recomendações em Executar Apache Cassandra em VMs do Azure.
Disponibilidade
As zonas de disponibilidade oferecem a melhor resiliência dentro de uma única região. Se você precisar de uma disponibilidade ainda maior, considere replicar o aplicativo em duas regiões.
Nem todas as regiões oferecem suporte a zonas de disponibilidade e nem todos os tamanhos de VM são suportados em todas as zonas. Execute o seguinte comando da CLI do Azure para localizar as zonas suportadas para cada tamanho de 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 essa arquitetura em uma região que não ofereça suporte a zonas de disponibilidade, coloque as VMs de cada camada dentro de 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 switches de rede para redundância. Os conjuntos de escala usam automaticamente grupos de posicionamento, que atuam como um conjunto de disponibilidade implícita.
Ao implantar em zonas de disponibilidade, use a SKU padrão do Balanceador de Carga do Azure e a SKU v2 do Application Gateway. Esses SKUs suportam redundância entre zonas. 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 o Application Gateway oferece suporte a alta disponibilidade e escalabilidade?
Uma única implantação do Application Gateway pode executar várias instâncias do gateway. Para cargas de trabalho de produção, execute pelo menos duas instâncias.
Aglomerado de 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 níveis de consistência e uso em Cassandra, consulte Configurando a consistência de dados e Cassandra: Quantos nós são conversados 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 a replicação no Cassandra, veja ata Replication in NoSQL Databases Explained (Replicação de dados nas bases de dados NoSQL explicada).
Sondas do estado de funcionamento
O Application Gateway e o Load Balancer usam testes de integridade para monitorar a disponibilidade de instâncias de VM.
- O Application Gateway sempre usa uma sonda HTTP.
- O Balanceador de Carga pode testar HTTP ou TCP. Geralmente, se uma VM executar um servidor HTTP, use uma sonda HTTP. Caso contrário, use TCP.
Se uma sonda não puder alcançar uma instância dentro de um período de tempo limite, o gateway ou balanceador de carga interromperá o envio de tráfego para essa VM. O teste continua a verificar e retornará a VM para o pool de back-end se a VM ficar disponível novamente.
As sondas 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 alguma lógica personalizada para verificar a integridade do aplicativo. O ponto final tem de permitir pedidos HTTP anónimos.
Para obter mais informações sobre sondas de saúde, consulte:
- Sondas de estado de funcionamento do Balanceador de Carga
- Visão geral do monitoramento de integridade do Application Gateway
Para obter considerações sobre como projetar um ponto de extremidade de teste de integridade, consulte Padrão de monitoramento de ponto de extremidade de integridade.
Otimização de custos
Use a Calculadora de Preços do Azure para estimar custos. Aqui estão algumas outras considerações.
Conjuntos de dimensionamento de máquinas virtuais
Os conjuntos de dimensionamento de máquina virtual estão disponíveis em todos os tamanhos de VM Linux. Ser-lhe-ão cobradas apenas as VMs do Azure que implementar, bem como os restantes recursos de infraestrutura subjacentes consumidos, como armazenamento e rede. Não existem custos adicionais para o próprio serviço de Conjuntos de Dimensionamento de Máquinas Virtuais.
Para opções de preços de VMs únicas, consulte Preços de VMs Linux.
Balanceadores de carga
Você será cobrado apenas pelo número de regras de balanceamento de carga e saída configuradas. As regras de NAT de entrada são gratuitas. Não existe uma tarifa por hora para o Balanceador de Carga Standard quando não tiverem sido configuradas regras.
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. As VMs em uma VNet não podem se comunicar diretamente com VMs em uma VNet diferente. As VMs dentro da mesma VNet podem comunicar, a menos que crie grupos de segurança de rede (NSGs) para restringir o tráfego. Para obter mais informações, veja Serviços cloud da Microsoft e segurança de rede.
No que concerne ao tráfego de entrada da Internet, as regras do balanceador de carga definem qual o tráfego que pode alcançar o back-end. No entanto, as regras do balanceador de carga não suportam listas de segurança de IP. Por isso, se pretender adicionar determinados endereços IP públicos para obter uma lista segura, adicione um NSG à sub-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. Para obter mais informações, veja Implementar uma rede de perímetro entre o Azure e a Internet.
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). Também é recomendado armazenar segredos de aplicativos, como cadeias de conexão de banco de dados, no Cofre de Chaves.
Proteção contra DDoS. A plataforma Azure fornece proteção básica contra DDoS por padrão. Esta proteção básica destina-se a proteger a infraestrutura do Azure como um todo. Embora a proteção básica contra DDoS esteja habilitada automaticamente, recomendamos o uso da Proteção de Rede 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 detetar ameaças. Isso permite que ele aplique mitigações contra ataques DDoS que podem passar despercebidos pelas políticas DDoS em toda a infraestrutura. A Proteção de Rede também fornece alertas, telemetria e análises através do Azure Monitor. Para obter mais informações, consulte 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 nesta arquitetura, eles estã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 de DevOps, para que a equipe possa gerenciar de forma independente todos os aspetos desses recursos. Esse isolamento permite que as equipes e serviços de DevOps realizem integração contínua e entrega contínua (CI/CD).
Além disso, você pode usar diferentes modelos de implantação e integrá-los aos Serviços de DevOps do Azure para provisionar ambientes diferentes em minutos, por exemplo, para replicar a produção, como cenários, 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, uma vez que 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, será necessária uma intervenção manual para movê-lo de volta ao seu estado correto. As Ferramentas de Gerenciamento de Configuração podem ser usadas para resolver esse problema.
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. O Application Insights é, na verdade, um dos componentes do Azure Monitor, que fornece métricas e logs avançados para verificar o estado de todo o cenário do Azure. O Azure Monitor irá ajudá-lo a acompanhar o estado da sua infraestrutura.
Certifique-se não apenas de monitorar seus elementos de computação que suportam o código do aplicativo, mas também sua plataforma de dados, em particular seus bancos de dados, uma vez que um baixo desempenho da camada de dados de um aplicativo pode ter sérias consequências.
Para testar o ambiente do Azure onde os aplicativos estão sendo executados, ele deve ser controlado por versão e implantado por meio dos mesmos mecanismos que o código do aplicativo, então ele pode ser testado e validado usando paradigmas de teste de DevOps também.
Para obter mais informações, consulte a seção Excelência Operacional no Microsoft Azure Well-Architecture Framework.