Applicazione a più livelli di Windows nell'hub di Azure Stack con SQL Server

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

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.

• Set di disponibilità. Il set di disponibilità è una configurazione del data center per garantire ridondanza e disponibilità delle macchine virtuali. Questa configurazione all'interno di un timbro dell'hub di Azure Stack garantisce che durante un evento di manutenzione pianificata o non pianificata sia disponibile almeno una macchina virtuale. Le macchine virtuali vengono inserite in un set di disponibilità che le distribuisce tra più domini di errore (host dell'hub di Azure Stack)

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.

• Load Balancer di livello 7. Poiché gateway applicazione non è ancora disponibile nell'hub di Azure Stack, sono disponibili alternative sul mercato dell'hub di Azure Stack, ad esempio: KEMP LoadMaster Load Balancer commutatore/ di contenuto ADCf5 Big-IP Virtual Edition o A10 vThunder ADC

• Servizi di bilanciamento del carico. Usare Azure Load Balancer per distribuire il traffico di rete dal livello Web al livello business e dal livello business al 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.

• DNS. L'hub di Azure Stack non fornisce il proprio servizio di hosting DNS, quindi usare il server DNS in ADDS.

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). Configurare i server Active Directory Domain Services nelle macchine virtuali nella stessa rete virtuale è preferibile aggiungere altre macchine virtuali ad Active Directory Domain Services. È anche possibile aggiungere le macchine virtuali a Enterprise AD DS esistenti connettendo la rete virtuale alla rete aziendale con connessione VPN. Con entrambi gli approcci, è necessario modificare il DNS della rete virtuale nel server DNS di Active Directory Domain Services (nella rete virtuale o nella rete aziendale esistente) per risolvere il nome di dominio completo del dominio di Active Directory Domain Services.

• 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 del piano di controllo. 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. Nell'hub di Azure Stack l'endpoint cloud di controllo è diverso da quello globale di Azure.

Può essere simile al seguente:

• Per Azure globale:
  https://mywitness.blob.core.windows.net/

• Per l'hub di Azure Stack:
  https://mywitness.blob.<region>.<FQDN>

• 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 Windows nell'hub di Azure Stack.

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.

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 Load Balancer di livello 7.

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.

1. Negare 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 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.

Per la disponibilità elevata a livello di macchina virtuale, tutte le macchine virtuali SQL devono trovarsi in un set di disponibilità.

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:

1. 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).

2. Creare un servizio di bilanciamento del carico interno con un indirizzo privato statico.

3. 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.

4. 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 più letture rispetto alle scritture, è possibile scaricare alcune delle query di sola lettura in 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à.

Per l'ottimizzazione delle prestazioni SQL, è anche possibile fare riferimento alle procedure consigliate di SQL Server per ottimizzare le prestazioni nell'hub di Azure Stack.

Jumpbox

Non consentire l'accesso RDP dalla rete Internet pubblica alle VM che eseguono il carico di lavoro dell'applicazione. Invece, tutti gli accessi RDP a queste macchine virtuali devono passare attraverso il jumpbox. Un amministratore accede al jumpbox, quindi accede alle altre macchine virtuali dal jumpbox. Il jumpbox consente il traffico RDP 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. 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.

Considerazioni sulla 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à semplifica la distribuzione e la gestione di un set di macchine virtuali identiche. Prendere in considerazione i set di scalabilità se è necessario aumentare rapidamente le macchine virtuali.

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à. Questa considerazione di progettazione è principalmente vera per l'hub di Azure Stack, ma esistono alcuni avvisi:

• I set di scalabilità di macchine virtuali nell'hub di Azure Stack non supportano l'overprovisioning o gli aggiornamenti in sequenza.

• Non è possibile ridimensionare automaticamente i set di scalabilità di macchine virtuali nell'hub di Azure Stack.

• È consigliabile usare i dischi gestiti nell'hub di Azure Stack anziché i dischi non gestiti per il set di scalabilità di macchine virtuali

• Attualmente, esiste un limite di 700 vm nell'hub di Azure Stack, che account per tutte le macchine virtuali dell'infrastruttura dell'hub di Azure Stack, le singole macchine virtuali e le istanze del set di scalabilità.

Limiti delle sottoscrizioni

Ogni sottoscrizione del tenant dell'hub di Azure Stack ha limiti predefiniti, inclusi un numero massimo di macchine virtuali per area configurate dall'operatore hub di Azure Stack. Per altre informazioni, vedere Servizi, piani, offerte, sottoscrizioni di Azure Stack Hub. Fare riferimento anche ai tipi di quota nell'hub di Azure Stack.

Considerazioni relative alla 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.

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.

Crittografia. Crittografare i dati sensibili inattivi e usare Key Vault nell'hub di Azure Stack per gestire le chiavi di crittografia del database. 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.

Passaggi successivi

• Per altre informazioni sui modelli cloud di Azure, vedere Modelli di progettazione cloud.