Questa architettura di riferimento illustra come distribuire macchine virtuali (VM) e una rete virtuale configurata per un'applicazione a più livelli, usando SQL Server in Windows per il livello dati.
Architettura
Scaricare un file di Visio di questa architettura.
Flusso di lavoro
L'architettura include i componenti indicati di seguito.
Generale
Gruppo di risorse. I gruppi di risorse vengono usati per raggruppare le risorse di Azure in modo che possano essere gestiti 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. 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 e dal livello business all'SQL Server.
Gruppi di sicurezza di rete.Network Security Groups (NSG). Usare i 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, che include funzionalità di mitigazione DDoS avanzate. Vedere Considerazioni sulla sicurezza.
DNS di Azure. DNS di Azure è un servizio di hosting per 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
SQL Server Always On gruppo di disponibilità. Assicura disponibilità elevata al livello dati, abilitando la replica e il failover. Usa la tecnologia Windows Server Failover Cluster (WSFC) per il failover.
Server di Active Directory Domain Services. Gli oggetti computer per il cluster di failover e i ruoli del cluster associati vengono creati in Active Directory Domain Services (AD DS).
Controllo cloud. Un cluster di failover richiede che più della metà dei nodi sia in esecuzione (quorum). Se il cluster ha solo due nodi, una partizione di rete potrebbe causare che ogni nodo pensi che si tratti del nodo primario. In tal caso, è necessario un controllo per stabilire la prevalenza e ottenere il quorum. Un controllo è una risorsa, ad esempio un disco condiviso, che può stabilire la prevalenza per ottenere il quorum. Il cloud di controllo è un tipo di controllo che usa Archiviazione BLOB di Azure. Per altre informazioni sul concetto di quorum, vedere Understanding cluster and pool quorum (Informazioni su cluster e quorum del pool). Per altre informazioni sul controllo cloud, vedere Distribuire un cloud di controllo per un cluster di failover.
Jumpbox. Detto anche bastion host. In genere, una macchina virtuale sicura nella rete 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. Il gruppo di sicurezza di rete deve consentire il traffico RDP (Remote Desktop Protocol). Azure offre la soluzione gestita Azure Bastion per soddisfare questa esigenza.
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 Windows 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. Dopo aver creato la rete virtuale, non è possibile modificare 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, ma assegnare invece a ogni VM un indirizzo IP privato. I client si connettono usando l'indirizzo IP pubblico associato al gateway applicazione.
Definire regole di bilanciamento del carico per indirizzare il traffico di rete alle macchine virtuali. Per consentire il traffico HTTP, ad esempio, eseguire il mapping della porta 80 della configurazione front-end alla porta 80 nel 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 nel pool di indirizzi back-end.
Gruppi di sicurezza di rete
Usare le regole NSG per limitare il traffico fra livelli. Nell'architettura a tre livelli illustrata sopra, il livello Web non comunica direttamente con il livello database. Per applicare questa regola, il livello di database deve bloccare il traffico in ingresso dalla subnet del livello Web.
- Negare tutto il traffico in ingresso dalla rete virtuale. (usare il tag
VIRTUAL_NETWORKnella regola). - Consentire il traffico in ingresso dalla subnet del livello business.
- 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.
- Consentire il traffico RDP (porta 3389) 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, quindi eseguirne l'override.
Gruppi di disponibilità Always On di SQL Server
È consigliabile usare i gruppi di disponibilità AlwaysOn per ottenere la disponibilità elevata di SQL Server. Nelle versioni precedenti a Windows Server 2016 i gruppi di disponibilità AlwaysOn richiedono un controller di dominio e tutti i nodi del gruppo di disponibilità devono far parte dello stesso dominio Active Directory.
Altri livelli si connettono al database tramite un listener del gruppo di disponibilità. Il listener consente a un client SQL di connettersi senza conoscere il nome dell'istanza fisica di SQL Server. Le macchine virtuali che accedono al database devono far parte del dominio. Il client (in questo caso un altro livello) usa il DNS per risolvere il nome della rete virtuale del listener in indirizzi IP.
Configurare il gruppo di disponibilità AlwaysOn di SQL Server nel modo seguente:
Creare un cluster WSFC (Windows Server Failover Clustering), un gruppo di disponibilità AlwaysOn di SQL Server e una replica primaria. Per altre informazioni, vedere Introduzione ai gruppi di disponibilità AlwaysOn (SQL Server).
Creare un servizio di bilanciamento del carico interno con un indirizzo privato statico.
Creare un listener del gruppo di disponibilità ed eseguire il mapping del nome DNS del listener all'indirizzo IP di un servizio di bilanciamento del carico interno.
Creare una regola di bilanciamento del carico per la porta di ascolto di SQL Server (porta TCP 1433 per impostazione predefinita). La regola di bilanciamento del carico deve abilitare l'indirizzo IP mobile, detto anche Direct Server Return, per fare in modo che la macchina virtuale risponda direttamente al client, permettendo una connessione diretta alla replica primaria.
Nota
Quando l'indirizzo IP mobile è abilitato, il numero di porta front-end deve corrispondere al numero di porta back-end nella regola di bilanciamento del carico.
Quando un client SQL cerca di connettersi, il servizio di bilanciamento del carico indirizza la richiesta di connessione alla replica primaria. In caso di failover a un'altra replica, il servizio di bilanciamento del carico indirizza automaticamente le nuove richieste a una nuova replica primaria. Per altre informazioni, vedere Configure an ILB listener for SQL Server Always On Availability Groups (Configurare un listener ILB per i gruppi di disponibilità AlwaysOn di SQL Server).
Durante un failover, le connessioni client esistenti vengono chiuse. Dopo il completamento del failover, le nuove connessioni verranno indirizzate alla nuova replica primaria.
Se l'applicazione esegue molte più letture che scritture, è possibile eseguire l'offload di alcune delle query di sola lettura a una replica secondaria. Vedere Utilizzo di un listener per connettersi a una replica secondaria di sola lettura (routing di sola lettura).
Testare la distribuzione forzando un failover manuale del gruppo di disponibilità.
Jumpbox
Quando si eseguono macchine virtuali in una rete virtuale privata, come in questa architettura, è necessario accedere alle macchine virtuali per l'installazione, l'applicazione di patch e così via. Tuttavia, rendere questi computer accessibili alla rete Internet pubblica non è una buona idea perché aumenta significativamente la superficie di attacco. Al contrario, un jumpbox viene usato come livello di accesso intermedio.
In passato, una macchina virtuale gestita dal cliente potrebbe essere usata come jumpbox. In questo scenario si applicano le raccomandazioni seguenti:
- Non consentire l'accesso RDP dalla rete Internet pubblica alle macchine virtuali che eseguono il carico di lavoro dell'applicazione. In alternativa, tutti gli accessi RDP a queste macchine virtuali devono passare attraverso il jumpbox. Un amministratore accede al jumpbox e quindi accede all'altra macchina virtuale dal jumpbox. Il jumpbox consente il traffico RDP da Internet, ma solo da indirizzi IP noti e sicuri.
- Il jumpbox ha requisiti di prestazioni minimi, quindi selezionare una macchina virtuale di piccole dimensioni. Creare un indirizzo IP pubblico per il jumpbox. Posizionare 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 RDP solo da un set di indirizzi IP pubblici attendibili. Configurare i gruppi di sicurezza di rete per le altre subnet per consentire il traffico RDP dalla subnet di gestione.
Per una macchina virtuale gestita dal cliente, si applicano tutte queste regole. Tuttavia, la raccomandazione corrente consiste nell'usare Azure Bastion, una soluzione jumpbox gestita che consente l'accesso HTML5 a RDP o SSH dietro la protezione di Azure AD. Si tratta di una soluzione molto più semplice che alla fine ha un costo totale di proprietà (TCO) inferiore per il cliente.
Considerazioni
Scalabilità
Set di scalabilità
Per i livelli Web e business, è consigliabile usare set di scalabilità di macchine virtuali anziché distribuire macchine virtuali separate. 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. Prendere in considerazione i set di scalabilità se è necessario aumentare rapidamente le istanze delle macchine virtuali o se si necessita del ridimensionamento automatico.
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à.
Suggerimento
Quando si usa una soluzione di ridimensionamento automatico, occorre testarla in anticipo con carichi di lavoro a livello di produzione.
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 Scalabilità automatica e ridondanza della zona gateway applicazione v2
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 in due aree usando Gestione traffico di Azure per il failover. Per altre informazioni, vedere Applicazione a più livelli per più aree per la disponibilità elevata.
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 dello stesso set di disponibilità vengono distribuite tra 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 in 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, vedere:
- Load Balancer Standard e zone di disponibilità
- Gateway applicazione con scalabilità automatica e ridondanza della zona versione 2
- In che modo il 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.
Probe di integrità
gateway applicazione e Load Balancer entrambi usano 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 ed è 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 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 Windows. Vengono addebitati solo i costi per le macchine virtuali di Azure distribuite e le eventuali risorse dell'infrastruttura sottostanti aggiuntive utilizzate, ad esempio l'archiviazione e la rete. Non sono previsti addebiti incrementali per il servizio set di scalabilità di macchine virtuali.
Per le opzioni dei prezzi delle macchine virtuali singole, 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à Always On e i computer controller di dominio. Esistono diverse opzioni di distribuzione a partire da un database singolo fino a un'istanza gestita o pool elastici. Per altre informazioni, vedere prezzi Azure SQL.
Per le opzioni dei prezzi delle macchine virtuali DI SQL Server, vedere Prezzi delle macchine virtuali SQL.
Servizi di bilanciamento del carico
Viene addebitato solo 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.
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. Per impostazione predefinita, le macchine virtuali in una rete virtuale non possono comunicare direttamente con macchine virtuali in una rete virtuale diversa. Tuttavia, è possibile connettere in modo esplicito le reti virtuali usando il peering di rete virtuale.
Gruppi di sicurezza di rete. Usare i gruppi di sicurezza di rete (NSG) per limitare il traffico verso e da Internet. Per altre informazioni, vedere Servizi cloud Microsoft e sicurezza di rete.
DMZ. 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. Per altre informazioni, vedere Configurare l'integrazione dell'insieme di credenziali delle chiavi di Azure per SQL Server in macchine virtuali di Azure (Resource Manager). È 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 offre 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 fatto semplifica l'associazione delle risorse specifiche del carico di lavoro a un team, in modo che il team possa gestire in modo indipendente tutti gli aspetti di tali risorse. Questo isolamento consente a DevOps 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 minuti, ad esempio per replicare 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 anti malware e agenti di sicurezza. Le estensioni della 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 errato in una fase successiva, richiederà un intervento manuale per spostarlo allo stato corretto.
Gli strumenti di gestione della configurazione, in particolare Desired State Configuration (DSC), vengono usati in questa architettura per configurare Active Directory e un gruppo di disponibilità SQL Server Always On.
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 di non solo monitorare gli elementi di calcolo che supportano il codice dell'applicazione, ma anche la piattaforma dati, in particolare i database, poiché una bassa 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 Azure Well-Architected Framework.