Eseguire un'applicazione livello N in più aree dell'hub di Azure Stack per la disponibilità elevata

Questa architettura di riferimento mostra un set di procedure comprovate per l'esecuzione in più aree dell'hub di Azure Stack per ottenere la disponibilità e un'infrastruttura di ripristino di emergenza affidabile. In questo documento Gestione traffico viene usato per ottenere la disponibilità elevata, tuttavia, se Gestione traffico non è una scelta preferita nell'ambiente, è possibile sostituire anche una coppia di servizi di bilanciamento del carico a disponibilità elevata.

Nota

Si noti che Gestione traffico usato nell'architettura seguente deve essere configurato in Azure e gli endpoint usati per configurare il profilo di Gestione traffico devono essere indirizzi IP instradabili pubblicamente.

Architettura

Questa architettura si basa su quella illustrata in Applicazione a più livelli con SQL Server.

• 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 separati per l'area primaria, l'area secondaria. In questo modo si ottiene la flessibilità necessaria per gestire ogni area come un'unica 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 degli indirizzi non si sovrappongano.

• SQL Server Always On gruppo di disponibilità. Se si usa SQL Server, è consigliabile usare i gruppi di disponibilità Always On di SQL Server per la disponibilità elevata. Creare un unico gruppo di disponibilità che includa le istanze di SQL Server in entrambe le aree.

• Connessione VPN da rete virtuale a rete virtuale. Poiché il peering reti virtuali non è ancora disponibile nell'hub di Azure Stack, usare la rete virtuale per la connessione VPN reti virtuali per connettere le due reti virtuali. Per altre informazioni, vedere Rete virtuale nella rete virtuale nell'hub di Azure Stack .

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 significa che le macchine virtuali nell'area secondaria sono allocate e in esecuzione in qualsiasi momento.

• Attivo/passivo con standby freddo. Il traffico viene indirizzato a un'area, mentre l'altra attende in modalità cold standby. Cold standby significa che le macchine virtuali nell'area secondaria non vengono allocate finché non diventa necessario 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 esclusa dalla rotazione.

Questa architettura di riferimento è incentrata sulla modalità attivo/passivo con hot standby, usando Gestione traffico per il failover. È possibile distribuire un numero ridotto di macchine virtuali per il hot standby e quindi aumentare le prestazioni in base alle esigenze.

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 degli endpoint di integrità.

Quando Gestione traffico effettua il failover, per un periodo di tempo 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.

Si noti che Gestione traffico effettua automaticamente il failback per impostazione predefinita. Per evitare questa situazione, 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 passare, tornare, 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 externalEndpoints --priority 3

Un altro approccio consiste nel disabilitare temporaneamente l'endpoint finché non si è pronti per eseguire il failback:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --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.

• Creare una VPN per abilitare la comunicazione tra due reti virtuali.

• 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. Configurarle per l'uso del commit sincrono con il failover automatico.

  • Inserire una o più repliche secondarie nell'area secondaria. Configurarle per l'uso del 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 sulla 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. In caso di interruzione del servizio Gestione traffico, i client non riescono ad accedere all'applicazione durante il tempo di inattività. Esaminare 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 problema potrebbe 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, sussiste il rischio di perdita dei 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:

  1. Passare temporaneamente una replica del database SQL Server nell'area secondaria al commit sincrono, in modo da garantire che non si verifichino perdite di dati durante il failover.

  2. Effettuare il failover a tale replica.

  3. Quando si effettua il failback all'area primaria, ripristinare l'impostazione di commit asincrono.

Considerazioni sulla gestibilità

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.

Passaggi successivi

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