Applicazione a più livelli di Windows nell'hub di Azure Stack con SQL Server
Questa architettura di riferimento illustra come distribuire macchine virtuali 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 seguenti.
Generale
gruppo di risorse. I gruppi di risorse vengono usati per raggruppare le risorse di Azure in modo che possano essere gestite in base alla durata, al proprietario o ad 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 li distribuisce tra più domini di errore (host dell'hub di Azure Stack)
Rete e bilanciamento del carico
Network virtuale e sottoreti. Ogni macchina virtuale di Azure viene distribuita in una rete virtuale che può essere segmentata in subnet. Creare una subnet separata per ogni livello.
Bilanciatore di carico di livello 7. Poiché il gateway applicazione non è ancora disponibile nell'hub di Azure Stack, sono disponibili alternative azure Stack Hub Market place, ad esempio: KEMP Load Balancer ADC Content Switch/ f5 Big-IP Virtual Edition o A10 vThunder ADC
dispositivi di bilanciamento del carico. Usare azure Load Balancer per distribuire il traffico di rete dal livello Web al livello business e dal livello business a SQL Server.
gruppi di sicurezza di rete (NSG). Usare gruppi di sicurezza di rete per limitare il traffico di rete all'interno della rete virtuale. Ad esempio, nell'architettura a tre livelli illustrata di seguito, il livello di database non accetta il traffico dal front-end Web, 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
Gruppo di disponibilità Always On di SQL Server. Offre disponibilità elevata al livello dati abilitando la replica e il failover. Utilizza la tecnologia WSFC (Windows Server Failover Cluster) per il failover.
Server dei servizi di dominio di Active Directory (AD DS). Gli oggetti computer per il cluster di failover e i relativi ruoli clusterizzati associati sono creati in Active Directory Domain Services (AD DS). Configurare i server di Active Directory Domain Services nelle macchine virtuali nella stessa rete virtuale è il metodo preferito per aggiungere altre macchine virtuali ad Active Directory Domain Services. È anche possibile aggiungere le macchine virtuali a Servizi di dominio Active Directory aziendali esistenti connettendo la rete virtuale alla rete aziendale con connessione VPN. Con entrambi gli approcci, è necessario modificare il DNS della rete virtuale al server DNS dei Servizi di dominio di Active Directory (AD DS) (sia nella rete virtuale che nella rete aziendale esistente) per risolvere il nome di dominio completo (FQDN) del dominio di AD DS.
Cloud Witness. Un cluster di failover richiede che più della metà dei suoi nodi siano attivi, che è noto come 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 testimone per risolvere le parità e stabilire il quorum. Una testimone è una risorsa, come un disco condiviso, che può fungere da fattore di rottura per stabilire il quorum. Cloud Witness è un tipo di testimone che utilizza Azure Blob Storage. Per altre informazioni sul concetto di quorum, vedere Understanding cluster and pool quorum. Per altre informazioni su Cloud Witness, vedere Distribuire un Cloud Witness per un cluster di failover. Nell'hub di Azure Stack, l'endpoint di Cloud Witness è diverso da Azure globale.
Potrebbe 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 host bastion . 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 sicuro. Il NSG dovrebbe consentire il traffico RDP (Remote Desktop Protocol).
Consigli
I requisiti potrebbero differire dall'architettura descritta qui. Usare questi consigli 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 abbastanza ampio per gli indirizzi IP necessari, usando la notazione CIDR . Usare uno spazio indirizzi che rientra negli standard dei blocchi di indirizzi IP privati, che sono 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 conto dei requisiti di funzionalità e sicurezza. Tutte le macchine virtuali all'interno dello stesso livello o ruolo devono entrare nella 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 macchine virtuali direttamente a Internet, ma assegnare a ogni macchina virtuale un indirizzo IP privato. I client si connettono usando l'indirizzo IP pubblico associato al servizio di bilanciamento del carico di livello 7.
Definire le regole del servizio di bilanciamento del carico per indirizzare il traffico di rete alle macchine virtuali. Ad esempio, per abilitare il traffico HTTP, eseguire il mapping della porta 80 dalla 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 seleziona un indirizzo IP back-end usando un algoritmo di hash che include l'indirizzo IP di origine. Le richieste client vengono distribuite in tutte le macchine virtuali nel pool di indirizzi back-end.
Gruppi di sicurezza di rete
Usare le regole del gruppo di sicurezza di rete (NSG) per limitare il traffico tra i livelli. Nell'architettura a tre livelli illustrata in precedenza, il livello Web non comunica direttamente con il livello di database. Per applicare questa regola, il livello del 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_NETWORK nella regola.
Consentire il traffico in ingresso dalla subnet del livello aziendale.
Consentire il traffico in ingresso dalla subnet del livello di database stesso. Questa regola consente la comunicazione tra le macchine virtuali del database, necessarie per la replica e il failover del database.
Consentire il traffico RDP (porta 3389) dalla sottorete jumpbox. Questa regola consente agli amministratori di connettersi al livello di database dal jumpbox.
Crea le regole 2 - 4 con priorità più alta rispetto alla prima regola, così da poterle sovrascrivere.
Gruppi di disponibilità AlwaysOn di SQL Server
Consigliamo Always On Availability Groups per l'alta disponibilità di SQL Server. Prima di Windows Server 2016, i gruppi di disponibilità AlwaysOn richiedono un controller di dominio e tutti i nodi del gruppo di disponibilità devono trovarsi nello stesso dominio di 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 essere aggiunte al dominio. Il client (in questo caso, un altro livello) usa DNS per risolvere il nome della rete virtuale del listener in indirizzi IP.
Configurare il gruppo di disponibilità AlwaysOn di SQL Server come indicato di seguito:
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.
Creare un servizio di bilanciamento del carico interno con un indirizzo IP privato statico.
Creare un listener del gruppo di disponibilità e associare il 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 IP mobile, detto anche Direct Server Return. In questo modo la macchina virtuale risponde direttamente al client, che consente una connessione diretta alla replica primaria.
Nota
Quando l'IP flottante è abilitato, il numero di porta front-end deve essere lo stesso del numero di porta back-end nella regola di bilanciamento del carico.
Quando un client SQL tenta di connettersi, il servizio di bilanciamento del carico instrada la richiesta di connessione alla replica primaria. Se è presente un failover in un'altra replica, il servizio di bilanciamento del carico instrada automaticamente le nuove richieste a una nuova replica primaria. Per ulteriori informazioni, consultare Configurare un listener ILB per i gruppi di disponibilità Always On di SQL Server.
Durante un failover, le connessioni client esistenti vengono chiuse. Al termine del failover, le nuove connessioni verranno instradate alla nuova replica primaria.
Se l'applicazione esegue più letture rispetto alle scritture, è possibile eseguire l'offload di alcune query di sola lettura in una replica secondaria. Vedere Uso di un listener per connettersi a una replica secondaria Read-Only (routingRead-Only).
Testare la distribuzione forzare un failover manuale del gruppo di disponibilità.
Per l'ottimizzazione delle prestazioni di SQL, è anche possibile fare riferimento all'articolo procedure consigliate per SQL Server per ottimizzare le prestazioni nell'hub di Azure Stack.
jumpbox
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 piccola dimensione della macchina virtuale. 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 sicuro di indirizzi IP pubblici. Configurare i gruppi di sicurezza di rete (NSG) per le altre sottoreti per consentire il traffico RDP dalla sottorete 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 di base per configurare le macchine virtuali distribuite in un set di scalabilità:
Usare le estensioni per configurare la macchina virtuale dopo la distribuzione. Con questo approccio, l'avvio di nuove istanze di macchine virtuali potrebbe richiedere più tempo rispetto a una macchina virtuale senza estensioni.
Distribuire un disco gestito con un'immagine disco personalizzata. Questa opzione può essere più rapida da distribuire. Tuttavia, è necessario mantenere l'immagine up-to-date.
Per ulteriori informazioni, vedere "Considerazioni sulla progettazione per i set di scalabilità" . Questa considerazione di progettazione è per lo più valida per l'hub di Azure Stack, ma esistono alcune avvertenze:
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 è previsto un limite di 700 macchine virtuali nell'hub di Azure Stack, che rappresenta 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 prevede limiti predefiniti, incluso un numero massimo di macchine virtuali per area configurate dall'operatore hub di Azure Stack. Per ulteriori informazioni, vedere Panoramica sui servizi, piani, offerte e sottoscrizioni di Azure Stack Hub. Vedere anche Tipi di quota nell'hub di Azure Stack.
Considerazioni sulla 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 le macchine virtuali in una rete virtuale diversa.
gruppi di sicurezza di rete. Usare gruppi di sicurezza di rete (NSG) per limitare il traffico da e verso Internet. Per altre informazioni, vedere servizi cloud Microsoft e sicurezza di rete.
DMZ. Prendere in considerazione l'aggiunta di un'appliance virtuale di rete per creare una rete perimetrale tra Internet e la rete virtuale di Azure. "NVA è un termine generico per un'appliance virtuale in grado di eseguire attività legate alla rete, come firewall, ispezione dei pacchetti, auditing e routing personalizzato."
Crittografia. Crittografa i dati sensibili quando sono inattivi e usa Key Vault in Azure Stack Hub per gestire le chiavi di crittografia del database. Per altre informazioni, vedere Configurare l'integrazione di Azure Key Vault per SQL Server su Azure VMs. È anche consigliabile archiviare i segreti dell'applicazione, ad esempio le stringhe di connessione del database, in Key Vault.
Passaggi successivi
- Per altre informazioni sui modelli cloud di Azure, vedere Modelli di progettazione cloud.