Applicazione a più livelli con Apache Cassandra

Questa architettura di riferimento illustra come distribuire macchine virtuali (VM) e una rete virtuale configurata per un'applicazione a più livelli tramite Apache Cassandra in Linux per il livello dati.

Architettura

Scaricare un file di Visio di questa architettura.

Workflow

L'architettura include i componenti indicati di seguito.

Generali

• Gruppo di risorse. I gruppi di risorse vengono usati per raggruppare le risorse di Azure in modo che possano essere gestite per durata, proprietario o altri criteri.

• Zone di disponibilità. Le zone di disponibilità sono posizioni fisiche all'interno di un'area di Azure. Ogni zona è costituita da uno o più data center con alimentazione, raffreddamento e rete indipendenti. Posizionando le macchine virtuali tra zone, l'applicazione diventa resiliente agli errori all'interno di una zona.

Rete e bilanciamento del carico

• Rete virtuale e subnet. Ogni macchina virtuale di Azure viene distribuita in una rete virtuale che può essere segmentata in subnet. Creare una subnet separata per ogni livello.

• Gateway applicazione. Il gateway applicazione è un servizio di bilanciamento del carico di livello 7. In questa architettura, instrada le richieste HTTP al front-end Web. Il gateway applicazione fornisce anche un Web application firewall (WAF) che protegge l'applicazione da exploit e vulnerabilità comuni.

• Servizi di bilanciamento del carico. Usare Azure Load Balancer Standard per distribuire il traffico di rete dal livello Web al livello business.

• Gruppi di sicurezza di rete (NSG). Usare gruppi di sicurezza di rete per limitare il traffico di rete all'interno della rete virtuale. Nell'architettura a tre livelli qui illustrata, ad esempio, il livello database non accetta traffico dal front-end Web, ma solo dal livello business e dalla subnet di gestione.

• Protezione DDoS. Anche se la piattaforma Azure offre protezione di base dagli attacchi DDoS (Distributed Denial of Service), è consigliabile usare Protezione di rete DDoS di Azure, con funzionalità avanzate di mitigazione DDoS. Vedere Le considerazioni sulla sicurezza .

• DNS di Azure. DNS di Azure è un servizio di hosting per i domini DNS che esegue la risoluzione dei nomi usando l'infrastruttura di Microsoft Azure. Ospitando i domini in Azure, è possibile gestire i record DNS usando le stesse credenziali, API, strumenti e fatturazione come per gli altri servizi Azure.

Macchine virtuali

• Database Apache Cassandra. Assicura disponibilità elevata al livello dati, abilitando la replica e il failover.

• OpsCenter. Distribuire una soluzione di monitoraggio, ad esempio DataStax OpsCenter , per monitorare il cluster Cassandra.

• JumpBox. detto anche bastion host. È una macchina virtuale sicura in rete che viene usata dagli amministratori per connettersi alle altre macchine virtuali. Il jumpbox ha un gruppo di sicurezza di rete che consente il traffico remoto solo da indirizzi IP pubblici inclusi in un elenco di indirizzi attendibili. L'NSG dovrebbe consentire il traffico RDP (Remote Desktop Protocol).

Consigli

I requisiti della propria organizzazione potrebbero essere diversi da quelli dell'architettura descritta in questo articolo. Usare queste indicazioni come punto di partenza.

Macchine virtuali

Per consigli sulla configurazione delle macchine virtuali, vedere Eseguire una macchina virtuale Linux in Azure.

Rete virtuale

Quando si crea la rete virtuale, determinare il numero di indirizzi IP necessari per le risorse in ogni subnet. Specificare una subnet mask e un intervallo di indirizzi di rete sufficientemente grande per gli indirizzi IP necessari, usando la notazione CIDR . Usare uno spazio indirizzi che rientri nei blocchi di indirizzi IP privati standard, ossia 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.

Scegliere un intervallo di indirizzi che non si sovrapponga alla rete locale, nel caso in cui sia necessario configurare un gateway tra la rete virtuale e la rete locale in un secondo momento. Una volta creata la rete virtuale, non è più possibile cambiare l'intervallo di indirizzi.

Progettare le subnet tenendo presenti i requisiti di funzionamento e sicurezza. Tutte le macchine virtuali nello stesso livello o nello stesso ruolo dovrebbero far parte della stessa subnet, che può essere un limite di sicurezza. Per altre informazioni sulla progettazione di reti virtuali e subnet, vedere Pianificare e progettare reti virtuali di Azure.

Gateway applicazione

Per informazioni sulla configurazione di gateway applicazione, vedere panoramica della configurazione di gateway applicazione.

Servizi di bilanciamento del carico

Non esporre le VM direttamente in Internet. Assegnare invece a ogni VM un indirizzo IP privato. I client si connettono usando l'indirizzo IP associato al gateway applicazione.

Definire regole di bilanciamento del carico per indirizzare il traffico di rete alle macchine virtuali. Ad esempio, per consentire il traffico HTTP, creare una regola che esegua il mapping della porta 80 dalla configurazione front-end alla porta 80 sul pool di indirizzi back-end. Quando un client invia una richiesta HTTP alla porta 80, il servizio di bilanciamento del carico consente di selezionare un indirizzo IP back-end usando un algoritmo di hash che include l'indirizzo IP di origine. Le richieste client vengono distribuite tra tutte le VM.

Gruppi di sicurezza di rete

Usare le regole NSG per limitare il traffico fra livelli. Nell'architettura a tre livelli illustrata sopra, ad esempio, il livello Web non comunica direttamente con il livello database. Per applicare questo comportamento, il livello database deve bloccare il traffico in entrata dalla subnet del livello Web.

1. Rifiutare tutto il traffico in ingresso dalla rete virtuale. (usare il tag VIRTUAL_NETWORK nella regola).
2. Consentire il traffico in ingresso dalla subnet del livello business.
3. Consentire il traffico in ingresso dalla subnet del livello database. Questa regola consente la comunicazione tra le macchine virtuali del database, condizione necessaria per la replica e il failover del database.
4. Consentire il traffico SSH (porta 22) dalla subnet del jumpbox. Questa regola consente agli amministratori di connettersi al livello database dal jumpbox.

Creare regole da 2 a 4 con priorità più alta rispetto alla prima regola, in modo da eseguirne l'override.

Cassandra

In ambiente di produzione è consigliabile usare DataStax Enterprise, ma questi suggerimenti sono validi per qualsiasi edizione di Cassandra. Per altre informazioni sull'esecuzione di DataStax in Azure, vedere DataStax Enterprise Deployment Guide for Azure (Guida alla distribuzione di DataStax Enterprise per Azure).

Configurare i nodi in modo che riconoscano il rack. Eseguire il mapping dei domini di errore ai rack nel file cassandra-rackdc.properties.

Non è necessario un servizio di bilanciamento del carico davanti al cluster. Il client si connette direttamente a un nodo nel cluster.

Gli script di distribuzione per questa architettura usano la risoluzione dei nomi per inizializzare il nodo di inizializzazione per la comunicazione tra cluster (gossip). Per abilitare la risoluzione dei nomi, la distribuzione crea una zona DNS privato di Azure con record A per i nodi Cassandra. A seconda degli script di inizializzazione, potrebbe essere invece possibile usare l'indirizzo IP statico.

Jumpbox

Non consentire l'accesso SSH dalla rete Internet pubblica alle VM che eseguono il carico di lavoro dell'applicazione. L'accesso SSH a queste macchine virtuali deve passare attraverso il jumpbox. Un amministratore accede al jumpbox, quindi accede alle altre macchine virtuali dal jumpbox. Il jumpbox consente il traffico SSH da Internet, ma solo da indirizzi IP conosciuti e attendibili.

Il jumpbox ha requisiti di prestazioni minimi, quindi selezionare una macchina virtuale di piccole dimensioni. Creare un indirizzo IP pubblico per il jumpbox. Collocare il jumpbox nella stessa rete virtuale delle altre macchine virtuali, ma in una subnet di gestione separata.

Per proteggere il jumpbox aggiungere una regola del gruppo di sicurezza di rete che consenta le connessioni SSH solo da un set di indirizzi IP pubblici attendibili. Configurare i gruppi di sicurezza di rete per le altre subnet per consentire il traffico SSH dalla subnet di gestione.

Considerazioni

Scalabilità

I set di scalabilità

Per i livelli Web e business, è consigliabile usare set di scalabilità di macchine virtuali anziché distribuire macchine virtuali separate in un set di disponibilità. Un set di scalabilità facilita la distribuzione e la gestione di un set di VM identiche e il ridimensionamento automatico delle VM in base alle metriche delle prestazioni. Di pari passo con l'aumento del carico sulle macchine virtuali, vengono aggiunte automaticamente altre macchine virtuali al servizio di bilanciamento del carico.

Esistono due modi per configurare le macchine virtuali distribuite in un set di scalabilità:

• Usare le estensioni per configurare la VM dopo la distribuzione. Con questo approccio, le nuove istanze delle macchine virtuali possono richiedere più tempo per l'avvio di una macchina virtuale senza estensioni.

• Distribuire un disco gestito con un'immagine del disco personalizzata. Questa opzione può risultare più veloce da distribuire. Richiede, tuttavia, che l'immagine venga mantenuta aggiornata.

Per altre informazioni, vedere Considerazioni sulla progettazione per i set di scalabilità.

Limiti delle sottoscrizioni

Ogni sottoscrizione di Azure ha limiti predefiniti, tra cui il numero massimo di macchine virtuali per area. È possibile aumentare il limite presentando una richiesta di supporto. Per altre informazioni, vedere Sottoscrizione di Azure e limiti, quote e vincoli dei servizi.

Gateway applicazione

gateway applicazione supporta la modalità di capacità fissa o la modalità di scalabilità automatica. La modalità di capacità fissa è utile per gli scenari con carichi di lavoro coerenti e prevedibili. È consigliabile usare la modalità di scalabilità automatica per i carichi di lavoro con traffico variabile. Per altre informazioni, vedere Gateway applicazione con scalabilità automatica e ridondanza della zona versione 2.

Efficienza prestazionale

Per ottenere prestazioni ottimali da Cassandra in macchine virtuali di Azure, vedere le raccomandazioni in Eseguire Apache Cassandra in macchine virtuali di Azure.

Disponibilità

Le zone di disponibilità offrono la migliore resilienza all'interno di una singola area. Se è necessaria una disponibilità ancora più elevata, valutare la possibilità di replicare l'applicazione tra due aree.

Non tutte le aree supportano le zone di disponibilità e non tutte le dimensioni delle macchine virtuali sono supportate in tutte le zone. Eseguire il comando seguente dell'interfaccia della riga di comando di Azure per trovare le zone supportate per ogni dimensione della macchina virtuale all'interno di un'area:

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

Se si distribuisce questa architettura in un'area che non supporta le zone di disponibilità, inserire le macchine virtuali per ogni livello all'interno di un set di disponibilità. Le macchine virtuali all'interno della stessa disponibilità vengono distribuite in più server fisici, rack di calcolo, unità di archiviazione e commutatori di rete per la ridondanza. I set di scalabilità usano automaticamente gruppi di posizionamento, che fungono da set di disponibilità impliciti.

Quando si esegue la distribuzione nelle zone di disponibilità, usare lo SKU Standard di Azure Load Balancer e lo SKU v2 di gateway applicazione. Questi SKU supportano la ridondanza tra zone. Per altre informazioni, vedi:

• Load Balancer Standard e zone di disponibilità
• Gateway applicazione con scalabilità automatica e ridondanza della zona versione 2
• In che modo gateway applicazione supporta la disponibilità elevata e la scalabilità?

Una singola distribuzione gateway applicazione può eseguire più istanze del gateway. Per i carichi di lavoro di produzione, eseguire almeno due istanze.

Cluster Cassandra

Per il cluster Cassandra, gli scenari di failover dipendono dai livelli di coerenza usati dall'applicazione e dal numero di repliche. Per i livelli di coerenza e l'utilizzo in Cassandra, vedere Configurazione della coerenza dei dati e Cassandra: quanti nodi vengono comunicare con il quorum? La disponibilità dei dati in Cassandra è determinata dal livello di coerenza usato dall'applicazione e dal meccanismo di replica. Per la replica in Cassandra, vedere Data Replication in NoSQL Databases Explained (Spiegazione della replica dei dati nei database NoSQL).

Probe di integrità

gateway applicazione e Load Balancer usano entrambi i probe di integrità per monitorare la disponibilità delle istanze di macchina virtuale.

• gateway applicazione usa sempre un probe HTTP.
• Load Balancer può testare HTTP o TCP. In genere, se una macchina virtuale esegue un server HTTP, usare un probe HTTP. In caso contrario, usare TCP.

Se un probe non riesce a raggiungere un'istanza entro un periodo di timeout, il gateway o il servizio di bilanciamento del carico interrompe l'invio del traffico a tale macchina virtuale. Il probe continua a controllare e restituirà la macchina virtuale al pool back-end se la macchina virtuale diventa nuovamente disponibile.

I probe HTTP inviano una richiesta HTTP GET a un percorso specificato e restare in ascolto di una risposta HTTP 200. Può trattarsi del percorso radice ("/") o di un endpoint di monitoraggio dell'integrità che implementa logica personalizzata per controllare l'integrità dell'applicazione. L'endpoint deve consentire richieste HTTP anonime.

Per altre informazioni sui probe di integrità, vedere:

• Probe di integrità di Load Balancer
• Panoramica del monitoraggio dell'integrità del gateway applicazione

Per considerazioni sulla progettazione di un endpoint del probe di integrità, vedere Modello di monitoraggio degli endpoint di integrità.

Ottimizzazione dei costi

Usare il Calcolatore prezzi di Azure per stimare i costi. Ecco alcune altre considerazioni.

set di scalabilità di macchine virtuali

I set di scalabilità di macchine virtuali sono disponibili in tutte le dimensioni delle macchine virtuali Linux. Ti verranno addebitate solo le VM di Azure distribuite, oltre a eventuali risorse di infrastruttura sottostanti che utilizzi, come quelle di archiviazione e di rete. Non viene applicato alcun addebito incrementale per il servizio dei set di scalabilità di macchine virtuali stesso.

Per le opzioni dei prezzi delle singole macchine virtuali, vedere Prezzi delle macchine virtuali Linux.

Servizi di bilanciamento del carico

Vengono addebitati solo il numero di regole di bilanciamento del carico e in uscita configurate. Le regole NAT in ingresso sono gratuite. Non è previsto alcun costo orario per il servizio Load Balancer Standard quando non è configurata alcuna regola.

Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.

Sicurezza

Le reti virtuali sono un limite di isolamento del traffico in Azure. Le VM in una rete virtuale non possono comunicare direttamente con quelle in un'altra rete virtuale. Le macchine virtuali all'interno della stessa rete virtuale possono comunicare, a meno che non si creino gruppi di sicurezza di rete per limitare il traffico. Per altre informazioni, vedere Servizi cloud Microsoft e sicurezza di rete.

Per il traffico Internet in ingresso, le regole di bilanciamento del carico definiscono il tipo di traffico che può raggiungere il back-end. Tuttavia, le regole di bilanciamento del carico non supportano gli elenchi di indirizzi IP attendibili, pertanto se si vogliono aggiungere determinati indirizzi IP pubblici a un elenco di indirizzi attendibili, aggiungere un gruppo di sicurezza di rete alla subnet.

Rete perimetrale. Valutare l'aggiunta di un'appliance virtuale di rete per creare una rete perimetrale tra la rete Internet e la rete virtuale di Azure. Un'appliance virtuale di rete esegue attività correlate alla rete, ad esempio impostazione di un firewall, ispezione di pacchetti, controllo e routing personalizzato. Per altre informazioni, vedere Implementazione di una rete perimetrale tra Azure e Internet.

Crittografia. Crittografare i dati sensibili inattivi e usareAzure Key Vault per gestire le chiavi di crittografia del database. Key Vault consente di archiviare le chiavi di crittografia in moduli di protezione hardware. È anche consigliabile archiviare in Key Vault i segreti dell'applicazione, ad esempio le stringhe di connessione di database.

Protezione DDoS. La piattaforma Azure offre protezione DDoS di base per impostazione predefinita. Tale protezione di base mira a proteggere l'infrastruttura complessiva di Azure. Anche se la protezione DDoS di base è abilitata automaticamente, è consigliabile usare Protezione di rete DDoS di Azure. Protezione di rete usa l'ottimizzazione adattiva, in base ai modelli di traffico di rete dell'applicazione, per rilevare le minacce. Ciò consente di applicare procedure di mitigazione per attacchi DDoS che potrebbero non essere rilevati dai criteri DDoS a livello di infrastruttura. Protezione di rete fornisce anche avvisi, dati di telemetria e analisi tramite Monitoraggio di Azure. Per altre informazioni, vedere Procedure consigliate per Protezione DDoS di Azure e architetture di riferimento.

Eccellenza operativa

Poiché tutte le risorse principali e le relative dipendenze si trovano nella stessa rete virtuale in questa architettura, sono isolate nello stesso carico di lavoro di base. Questo rende più semplice associare le risorse specifiche del carico di lavoro a un team DevOps, in modo che il team possa gestire in modo indipendente tutti gli aspetti di tali risorse. Questo isolamento consente a DevOps Teams e Ai servizi di eseguire l'integrazione continua e il recapito continuo (CI/CD).

È anche possibile usare modelli di distribuzione diversi e integrarli con Azure DevOps Services per effettuare il provisioning di ambienti diversi in pochi minuti, ad esempio per replicare la produzione, ad esempio scenari o ambienti di test di carico solo quando necessario, risparmiando i costi.

In questo scenario, le macchine virtuali vengono configurate usando estensioni macchina virtuale, poiché offrono la possibilità di installare determinati software aggiuntivi, ad esempio Apache Cassandra. In particolare, l'estensione per script personalizzati consente il download e l'esecuzione di codice arbitrario in una macchina virtuale, consentendo una personalizzazione illimitata del sistema operativo di una macchina virtuale di Azure. Le estensioni macchina virtuale vengono installate ed eseguite solo in fase di creazione della macchina virtuale. Ciò significa che se il sistema operativo viene configurato in modo non corretto in una fase successiva, richiederà un intervento manuale per riportarlo allo stato corretto. Gli strumenti di gestione della configurazione possono essere usati per risolvere questo problema.

Valutare se usare Monitoraggio di Azure per analizzare e ottimizzare le prestazioni dell'infrastruttura, monitorare e diagnosticare i problemi di rete senza accedere alle macchine virtuali. Application Insights è effettivamente uno dei componenti di Monitoraggio di Azure che offre metriche e log dettagliati per verificare lo stato di tutto il panorama di Azure. Monitoraggio di Azure consente di seguire lo stato dell'infrastruttura.

Assicurarsi non solo di monitorare gli elementi di calcolo che supportano il codice dell'applicazione, ma anche la piattaforma dati, in particolare i database, in quanto una riduzione delle prestazioni del livello dati di un'applicazione potrebbe avere gravi conseguenze.

Per testare l'ambiente di Azure in cui sono in esecuzione le applicazioni, deve essere controllato dalla versione e distribuito tramite gli stessi meccanismi del codice dell'applicazione, quindi può essere testato e convalidato anche usando i paradigmi di test devOps.

Per altre informazioni, vedere la sezione Eccellenza operativa in Microsoft Azure Well-Architecture Framework.

Passaggi successivi

• Modulo Di Microsoft Learn: Presentazione dello stile dell'architettura a più livelli