Questa architettura di riferimento mostra un set di procedure consolidate per l'esecuzione di un'applicazione a più livelli in più aree di Azure, per ottenere disponibilità e un'infrastruttura di ripristino di emergenza affidabile.
Architettura
Scaricare un file di Visio di questa architettura.
Workflow
Aree primarie e secondarie. Usare due aree per ottenere una maggiore disponibilità: una è l'area primaria, l'altra è per il failover.
Gestione traffico di Azure. Gestione traffico indirizza le richieste in ingresso a una delle aree. Durante il normale funzionamento, le richieste vengono indirizzate all'area primaria. Se tale area non è più disponibile, Gestione traffico effettua il failover all'area secondaria. Per altre informazioni, vedere la sezione Configurazione di Gestione traffico.
Gruppi di risorse. Creare gruppi di risorse distinti per l'area primaria, l'area secondaria e Gestione traffico. Questo metodo offre la flessibilità necessaria per gestire ogni area come singola raccolta di risorse. Ad esempio, è possibile ridistribuire un'area, senza rendere non disponibile l'altra. Collegare i gruppi di risorse, in modo che sia possibile eseguire una query per elencare tutte le risorse per l'applicazione.
Reti virtuali. Creare una rete virtuale separata per ogni area. Assicurarsi che gli spazi indirizzi non si sovrappongano.
Gruppo di disponibilità Always On di SQL Server. Se si usa SQL Server, è consigliabile usare i gruppi di disponibilità SQL AlwaysOn per la disponibilità elevata. Creare un unico gruppo di disponibilità che includa le istanze di SQL Server in entrambe le aree.
Nota
Prendere in considerazione anche l'uso del database SQL di Azure, che fornisce un database relazionale come servizio cloud. Con il database SQL, non è necessario configurare un gruppo di disponibilità o gestire il failover.
Peering di reti virtuali. Eseguire il peering delle due reti virtuali per consentire la replica dei dati dall'area primaria all'area secondaria. Per altre informazioni, vedere Peering di rete virtuale.
Componenti
- I set di disponibilità assicurano che le in Azure le macchine virtuali vengano distribuite tra più nodi hardware isolati in un cluster. Se si verifica un errore hardware o software in Azure, solo un subset delle macchine virtuali è interessato e l'intera soluzione rimane disponibile e operativa.
- Le zone di disponibilità proteggono le applicazioni e i dati dai guasti del data center. Le zone di disponibilità sono località fisiche separate all'interno di un'area di Azure. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete.
- Gestione traffico di Azure è un servizio di bilanciamento del carico del traffico basato su DNS che distribuisce il traffico in modo ottimale. Offre servizi in aree di Azure globali, con disponibilità elevata e velocità di risposta.
- Azure Load Balancer distribuisce il traffico in ingresso, in base alle regole definite e ai probe di integrità. Un servizio di bilanciamento del carico offre bassa latenza e velocità effettiva elevata, aumentando le prestazioni fino a milioni di flussi per tutte le applicazioni TCP e UDP. In questo scenario viene usato un servizio di bilanciamento del carico pubblico per distribuire il traffico client in ingresso al livello Web. In questo scenario viene usato un servizio di bilanciamento del carico interno per distribuire il traffico dal livello business al cluster SQL Server back-end.
- Azure Bastion offre connettività RDP e SSH sicura a tutte le macchine virtuali, nella rete virtuale in cui viene effettuato il provisioning. Usare Azure Bastion per proteggere le macchine virtuali dall'esposizione di porte RDP/SSH all'esterno, garantendo comunque l'accesso sicuro tramite RDP/SSH.
Consigli
Un'architettura di tipo multi-area può fornire una maggiore disponibilità rispetto alla distribuzione in un'unica area. Se un'interruzione a livello di area interessa l'area primaria, è possibile usare Gestione traffico per effettuare il failover all'area secondaria. Questa architettura è utile anche in caso di errore di un singolo sottosistema dell'applicazione.
Sono disponibili diversi approcci generali per ottenere una disponibilità elevata tra le diverse aree geografiche:
- Attivo/passivo con hot standby. Il traffico viene indirizzato a un'area, mentre l'altra attende in modalità hot standby. Hot standby indica che le macchine virtuali nell'area secondaria vengono allocate e sono sempre in esecuzione.
- Attivo/passivo con cold standby. Il traffico viene indirizzato a un'area, mentre l'altra attende in modalità cold standby. Standby sporadico indica che le macchine virtuali nell'area secondaria non vengono allocate fino a quando non sono necessarie per il failover. Questo approccio presenta costi inferiori in termini di esecuzione, ma in genere richiederà più tempo per portare online le risorse in caso di errore.
- Attivo/attivo. Entrambe le aree sono attive e viene effettuato un bilanciamento del carico tra le richieste. Se un'area non è più disponibile, viene estratta dalla rotazione.
Questa architettura di riferimento è incentrata sulla modalità attivo/passivo con hot standby, usando Gestione traffico per il failover. È possibile distribuire alcune macchine virtuali per hot standby e quindi aumentare il numero di istanze in base alle esigenze.
Coppie di aree
Ogni area di Azure è abbinata a un'altra area con la stessa collocazione geografica. In generale, è consigliabile scegliere aree della stessa coppia di aree (ad esempio, Stati Uniti orientali 2 e Stati Uniti centrali). I vantaggi di questi armadietti sono:
- Se si verifica un'interruzione generale, il ripristino di almeno un'area all'esterno di ogni coppia è prioritario.
- Gli aggiornamenti di sistema di Azure pianificati vengono implementati in sequenza tra le aree abbinate, per ridurre al minimo l'eventuale tempo di inattività.
- Le coppie si trovano nella stessa area geografica, per soddisfare i requisiti di residenza dei dati.
Assicurarsi tuttavia che entrambe le aree supportino tutti i servizi di Azure necessari per l'applicazione (vedere i servizi disponibili in base all'area). Per altre informazioni sulle coppie di aree, vedere Continuità aziendale e ripristino di emergenza nelle aree geografiche abbinate di Azure.
Configurazione di Gestione traffico
Quando si configura Gestione traffico, tenere presente quanto segue:
- Routing. Gestione traffico supporta diversi algoritmi di routing. Per lo scenario descritto in questo articolo, usare il routing Priorità (precedentemente denominato routing Failover). Con questa impostazione, Gestione traffico invia tutte le richieste all'area primaria, a meno che l'area primaria non diventi irraggiungibile. A questo punto, viene automaticamente effettuato il failover all'area secondaria. Vedere Configurare il metodo di routing failover.
- Probe di integrità. Gestione traffico usa un probe HTTP (o HTTPS) per monitorare la disponibilità di ogni area. Il probe verifica una risposta HTTP 200 per un percorso URL specificato. Come procedura consigliata, creare un endpoint che segnali l'integrità complessiva dell'applicazione e usare questo endpoint per il probe di integrità. In caso contrario, il probe potrebbe segnalare un endpoint integro quando le parti più importanti dell'applicazione in realtà hanno esito negativo. Per altre informazioni, vedere Modello di monitoraggio endpoint di integrità.
Quando Gestione traffico viene eseguito il failover, si verifica un periodo di tempo in cui i client non riescono a raggiungere l'applicazione. La durata di questo periodo è influenzata dai fattori seguenti:
- Il probe di integrità deve rilevare che l'area primaria è diventata irraggiungibile.
- I server DNS devono aggiornare i record DNS memorizzati nella cache per l'indirizzo IP, che dipende dalla durata (TTL) DNS. Il valore TTL predefinito è di 300 secondi (5 minuti), ma è possibile configurare questo valore durante la creazione del profilo di Gestione traffico.
Per dettagli, vedere Informazioni sul monitoraggio di Gestione traffico.
Se Gestione traffico effettua il failover, è consigliabile eseguire un failback manuale invece di implementare un failback automatico. In caso contrario, si potrebbe creare una situazione in cui l'applicazione passa alternativamente da un'area all'altra. Verificare che tutti i sottosistemi dell'applicazione siano integri prima del failback.
Gestione traffico viene eseguito automaticamente il failback per impostazione predefinita. Per evitare questo problema, ridurre manualmente la priorità dell'area primaria dopo un evento di failover. Ad esempio, si supponga che l'area primaria sia di priorità 1 e la secondaria di priorità 2. Dopo un failover, impostare l'area primaria sul livello di priorità 3 per evitare il failback automatico. Quando si è pronti per tornare indietro, aggiornare la priorità a 1.
Il comando seguente dell'interfaccia della riga di comando di Azure aggiorna la priorità:
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --priority 3
Un altro approccio consiste nel disabilitare temporaneamente l'endpoint fino a quando non si è pronti a eseguire il failback:
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --endpoint-status Disabled
A seconda della causa di un failover, potrebbe essere necessario ridistribuire le risorse all'interno di un'area. Prima di eseguire nuovamente il failback, eseguire un test della conformità operativa, che avrà lo scopo di verificare gli elementi seguenti:
- Le macchine virtuali sono configurate correttamente (tutto il software richiesto è installato, IIS è in esecuzione e così via).
- I sottosistemi dell'applicazione sono integri.
- Test funzionale (ad esempio, il livello del database è raggiungibile dal livello Web).
Configurare i gruppi di disponibilità Always On di SQL Server
Nelle versioni precedenti a Windows Server 2016 i gruppi di disponibilità Always On di SQL Server richiedono un controller di dominio e tutti i nodi del gruppo di disponibilità devono far parte dello stesso dominio Active Directory (AD).
Per configurare il gruppo di disponibilità:
Collocare almeno due controller di dominio in ogni area.
Assegnare a ogni controller di dominio un indirizzo IP statico.
Eseguire il peering delle due reti virtuali per consentire la comunicazione tra di esse.
Per ogni rete virtuale, aggiungere gli indirizzi IP dei controller di dominio (da entrambe le aree) all'elenco dei server DNS. È possibile usare il comando dell'interfaccia della riga di comando seguente. Per altre informazioni, vedere Modificare i server DNS.
az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"Creare un Windows Server Failover Clustering (WSFC) che includa le istanze di SQL Server in entrambe le aree.
Creare un gruppo di disponibilità Always On di SQL Server che includa le istanze di SQL Server in entrambe le aree primaria e secondaria. Per la procedura, vedere Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) (Estensione del gruppo di disponibilità Always On al data center di Azure remoto (PowerShell)).
Inserire la replica primaria nell'area primaria.
Inserire una o più repliche secondarie nell'area primaria. Configurare queste repliche per l'uso del commit sincrono con failover automatico.
Inserire una o più repliche secondarie nell'area secondaria. Configurare queste repliche per usare il commit asincrono , per motivi di prestazioni. (in caso contrario, tutte le transazioni T-SQL dovranno attendere l'esecuzione di un round trip in rete all'area secondaria).
Nota
Le repliche con commit asincrono non supportano il failover automatico.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Disponibilità
Con un'app complessa a più livelli, potrebbe non essere necessario replicare l'intera applicazione nell'area secondaria. In alternativa, è possibile replicare solo un sottosistema critico indispensabile per supportare la continuità aziendale.
Gestione traffico è un possibile punto di guasto nel sistema. Se il servizio Gestione traffico ha esito negativo, i client non possono accedere all'applicazione durante il tempo di inattività. Rivedere il contratto di servizio di Gestione traffico e determinare se l'uso di Gestione traffico da solo soddisfa i requisiti aziendali per la disponibilità elevata. In caso contrario, provare ad aggiungere un'altra soluzione di gestione del traffico come failback. In caso di errore del servizio Gestione traffico di Azure, modificare i record CNAME in DNS in modo che puntino all'altro servizio di gestione del traffico. (questo passaggio deve essere eseguito manualmente e l'applicazione non sarà disponibile finché non vengono propagate le modifiche al DNS).
Per il cluster di SQL Server, sono da considerare due scenari di failover:
Tutte le repliche del database SQL Server nell'area primaria hanno esito negativo. Ad esempio, questo errore può verificarsi durante un'interruzione a livello di area. In questo caso, è necessario effettuare manualmente il failover del gruppo di disponibilità, anche se Gestione traffico effettua il failover automaticamente sul front-end. Seguire i passaggi in Eseguire un failover manuale forzato di un gruppo di disponibilità di SQL Server, che descrive come effettuare un failover forzato usando SQL Server Management Studio, Transact-SQL o PowerShell in SQL Server 2016.
Avviso
Con il failover forzato, esiste un rischio di perdita di dati. Quando l'area primaria torna online, eseguire uno snapshot del database e usare tablediff per individuare le differenze.
Gestione traffico effettua il failover all'area secondaria, ma la replica primaria del database SQL Server è ancora disponibile. Ad esempio, nel livello front-end potrebbe verificarsi un errore che non si ripercuote sulle macchine virtuali di SQL Server. In tal caso, il traffico Internet viene indirizzato all'area secondaria e tale area può comunque connettersi alla replica primaria. Tuttavia, vi sarà un aumento della latenza, poiché le connessioni di SQL Server attraversano le aree geografiche. In questa situazione è necessario effettuare un failover manuale come indicato di seguito:
- Passare temporaneamente una replica del database SQL Server nell'area secondaria al commit sincrono, Questo passaggio garantisce che non si verifichino perdite di dati durante il failover.
- Effettuare il failover a tale replica.
- Quando si effettua il failback all'area primaria, ripristinare l'impostazione di commit asincrono.
Gestione
Quando si aggiorna la distribuzione, aggiornare un'area alla volta per ridurre la probabilità di un errore globale da una configurazione errata o un errore nell'applicazione.
Testare la resilienza del sistema agli errori. Di seguito sono riportati alcuni scenari di errore comuni da testare:
- Arrestare le istanze di macchina virtuale.
- Esercitare un uso elevato delle risorse come CPU e memoria.
- Disconnettere/ritardare la rete.
- Arrestare in modo anomalo i processi.
- Far scadere i certificati.
- Simulare errori hardware.
- Arrestare il servizio DNS nei controller di dominio.
Misurare i tempi di ripristino e verificare che soddisfino i requisiti aziendali. Testare anche le combinazioni di modalità di errore.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Usare il Calcolatore prezzi di Azure per stimare i costi. Di seguito alcune ulteriori considerazioni.
Set di scalabilità di macchine virtuali
set di scalabilità di macchine virtuali sono disponibili in tutte le dimensioni delle macchine virtuali Windows. Vengono addebitati solo i costi per le macchine virtuali di Azure distribuite e per le risorse dell'infrastruttura sottostanti aggiunte utilizzate, ad esempio archiviazione e rete. Non sono previsti addebiti incrementali per il servizio set di scalabilità di macchine virtuali.
Per le opzioni dei prezzi delle singole macchine virtuali, vedere Prezzi delle macchine virtuali Windows.
SQL server
Se si sceglie Azure SQL DBaas, è possibile risparmiare sui costi perché non è necessario configurare un gruppo di disponibilità AlwaysOn e i computer controller di dominio. Sono disponibili diverse opzioni di distribuzione a partire da un database singolo fino a un'istanza gestita o a pool elastici. Per altre informazioni, vedere Prezzi di Azure SQL.
Per le opzioni dei prezzi delle macchine virtuali di SQL Server, vedere Prezzi delle macchine virtuali SQL.
Servizi di bilanciamento del carico
Vengono addebitati solo i costi per il numero di regole di bilanciamento del carico e in uscita configurate. Le regole NAT in ingresso sono gratuite. Non è previsto alcun addebito orario per il Load Balancer Standard quando non sono configurate regole.
Prezzi per Gestione traffico
La fatturazione di Gestione traffico è basata sul numero di query DNS ricevute, con uno sconto per i servizi che ricevono più di 1 miliardo di query al mese. Viene addebitato anche il costo per ogni endpoint monitorato.
Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.
Prezzi del peering reti virtuali
Una distribuzione a disponibilità elevata che usa più aree di Azure userà il peering reti virtuali. Sono previsti addebiti diversi per il peering reti virtuali all'interno della stessa area e per il peering reti virtuali globali.
Per altre informazioni, vedere prezzi Rete virtuale.
DevOps
Usare un singolo modello di Azure Resource Manager per il provisioning delle risorse di Azure e delle relative dipendenze. Usare lo stesso modello per distribuire le risorse in aree primarie e secondarie. Includere tutte le risorse nella stessa rete virtuale in modo che siano isolate nello stesso carico di lavoro di base. Includendo tutte le risorse, è 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 Team e Services di eseguire l'integrazione continua e il recapito continuo (CI/CD).
È anche possibile usare modelli di Azure Resource Manager diversi e integrarli con Azure DevOps Services per effettuare il provisioning di ambienti diversi in pochi minuti, ad esempio per replicare ambienti di produzione come scenari o ambienti di test di carico solo quando necessario, risparmiando i costi.
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-Architected Framework.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Donnie Trumpower | Senior Cloud Solution Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Risorse correlate
L'architettura seguente usa alcune delle stesse tecnologie: