Eseguire un'applicazione a più livelli in più aree di hub Azure Stack per la disponibilità elevataRun an N-tier application in multiple Azure Stack Hub regions for high availability

Questa architettura di riferimento Mostra un set di procedure consolidate per l'esecuzione in un'applicazione a più livelli più aree Azure Stack Hub, per ottenere la disponibilità e un'infrastruttura di ripristino di emergenza affidabile.This reference architecture shows a set of proven practices for running across an N-tier application multiple Azure Stack Hub regions, in order to achieve availability and a robust disaster recovery infrastructure. In questo documento, gestione traffico viene usato per ottenere la disponibilità elevata, tuttavia se Gestione traffico non è una scelta preferita nell'ambiente in uso, è possibile sostituire anche una coppia di bilanciamenti del carico a disponibilità elevata.In this document, Traffic Manager is used to achieve high availability, however if Traffic Manager is not a preferred choice in your environment, a pair of highly available load balancers could also be substituted in.

Nota

Si noti che gestione traffico usato nell'architettura di seguito deve essere configurato in Azure e gli endpoint usati per configurare il profilo di gestione traffico devono essere indirizzi IP instradabili pubblicamente.Please note the Traffic Manager used in the architecture below needs to be configured in Azure and the endpoints used to configure the Traffic Manager profile need to be publicly routable IPs.

ArchitectureArchitecture

Questa architettura si basa su quella illustrata in Applicazione a più livelli con SQL Server.This architecture builds on the one shown in N-tier application with SQL Server.

Architettura di rete a disponibilità elevata per applicazioni Azure a più livelli

  • Aree primarie e secondarie.Primary and secondary regions. Usare due aree per ottenere una maggiore disponibilità:Use two regions to achieve higher availability. una è l'area primaria,One is the primary region. l'altra è per il failover.The other region is for failover.

  • Gestione traffico di Azure.Azure Traffic Manager. Gestione traffico indirizza le richieste in ingresso a una delle aree.Traffic Manager routes incoming requests to one of the regions. Durante il normale funzionamento, le richieste vengono indirizzate all'area primaria.During normal operations, it routes requests to the primary region. Se tale area non è più disponibile, Gestione traffico effettua il failover all'area secondaria.If that region becomes unavailable, Traffic Manager fails over to the secondary region. Per altre informazioni, vedere la sezione Configurazione di Gestione traffico.For more information, see the section Traffic Manager configuration.

  • Gruppi di risorse.Resource groups. Creare gruppi di risorse distinti per l'area primaria, l'area secondaria.Create separate resource groups for the primary region, the secondary region. In questo modo si ottiene la flessibilità necessaria per gestire ogni area come un'unica raccolta di risorse.This gives you the flexibility to manage each region as a single collection of resources. Ad esempio, è possibile ridistribuire un'area, senza rendere non disponibile l'altra.For example, you could redeploy one region, without taking down the other one. Collegare i gruppi di risorse, in modo che sia possibile eseguire una query per elencare tutte le risorse per l'applicazione.Link the resource groups, so that you can run a query to list all the resources for the application.

  • Reti virtuali.Virtual networks. Creare una rete virtuale separata per ogni area.Create a separate virtual network for each region. Assicurarsi che gli spazi degli indirizzi non si sovrappongano.Make sure the address spaces do not overlap.

  • SQL Server Always on gruppo di disponibilità.SQL Server Always On Availability Group. Se si usa SQL Server, è consigliabile usare i gruppi di disponibilità Always On di SQL Server per la disponibilità elevata.If you are using SQL Server, we recommend SQL Always On Availability Groups for high availability. Creare un unico gruppo di disponibilità che includa le istanze di SQL Server in entrambe le aree.Create a single availability group that includes the SQL Server instances in both regions.

  • VNET alla connessione VPN VNET.VNET to VNET VPN Connection. Poiché Peering reti virtuali non è ancora disponibile nell'hub Azure Stack, usare VNET per VNET connessione VPN per connettere i due reti virtuali.As VNET Peering is not yet available on Azure Stack Hub, use VNET to VNET VPN connection in order to connect the two VNETs. Per ulteriori informazioni, vedere VNET per VNET nell'Hub Azure stack .Please see VNET to VNET in Azure Stack Hub for more information.

ConsigliRecommendations

Un'architettura di tipo multi-area può fornire una maggiore disponibilità rispetto alla distribuzione in un'unica area.A multi-region architecture can provide higher availability than deploying to a single region. Se un'interruzione a livello di area interessa l'area primaria, è possibile usare Gestione traffico per effettuare il failover all'area secondaria.If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region. Questa architettura è utile anche in caso di errore di un singolo sottosistema dell'applicazione.This architecture can also help if an individual subsystem of the application fails.

Sono disponibili diversi approcci generali per ottenere una disponibilità elevata tra le diverse aree geografiche:There are several general approaches to achieving high availability across regions:

  • Attivo/passivo con hot standby.Active/passive with hot standby. Il traffico viene indirizzato a un'area, mentre l'altra attende in modalità hot standby.Traffic goes to one region, while the other waits on hot standby. Hot standby significa che le macchine virtuali nell'area secondaria sono allocate e in esecuzione in qualsiasi momento.Hot standby means the VMs in the secondary region are allocated and running at all times.

  • Attivo/passivo con Cold standby.Active/passive with cold standby. Il traffico viene indirizzato a un'area, mentre l'altra attende in modalità cold standby.Traffic goes to one region, while the other waits on cold standby. Cold standby significa che le macchine virtuali nell'area secondaria non vengono allocate finché non diventa necessario per il failover.Cold standby means the VMs in the secondary region are not allocated until needed for 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.This approach costs less to run, but will generally take longer to come online during a failure.

  • Attivo/attivo.Active/active. Entrambe le aree sono attive e viene effettuato un bilanciamento del carico tra le richieste.Both regions are active, and requests are load balanced between them. Se un'area non è più disponibile, viene esclusa dalla rotazione.If one region becomes unavailable, it is taken out of rotation.

Questa architettura di riferimento è incentrata sulla modalità attivo/passivo con hot standby, usando Gestione traffico per il failover.This reference architecture focuses on active/passive with hot standby, using Traffic Manager for failover. È possibile distribuire un numero ridotto di macchine virtuali per hot standby e quindi scalare in orizzontale in base alle esigenze.You could deploy a small number of VMs for hot standby and then scale out as needed.

Configurazione di Gestione trafficoTraffic Manager configuration

Quando si configura Gestione traffico, tenere presente quanto segue:Consider the following points when configuring Traffic Manager:

  • Routing.Routing. Gestione traffico supporta diversi algoritmi di routing.Traffic Manager supports several routing algorithms. Per lo scenario descritto in questo articolo, usare il routing Priorità (precedentemente denominato routing Failover).For the scenario described in this article, use priority routing (formerly called failover routing). Con questa impostazione, Gestione traffico invia tutte le richieste all'area primaria, a meno che l'area primaria non diventi irraggiungibile.With this setting, Traffic Manager sends all requests to the primary region, unless the primary region becomes unreachable. A questo punto, viene automaticamente effettuato il failover all'area secondaria.At that point, it automatically fails over to the secondary region. Vedere Configurare il metodo di routing failover.See Configure Failover routing method.

  • Probe di integrità.Health probe. Gestione traffico usa un probe HTTP (o HTTPS) per monitorare la disponibilità di ogni area.Traffic Manager uses an HTTP (or HTTPS) probe to monitor the availability of each region. Il probe verifica una risposta HTTP 200 per un percorso URL specificato.The probe checks for an HTTP 200 response for a specified URL path. Come procedura consigliata, creare un endpoint che segnali l'integrità complessiva dell'applicazione e usare questo endpoint per il probe di integrità.As a best practice, create an endpoint that reports the overall health of the application, and use this endpoint for the health probe. In caso contrario, il probe potrebbe segnalare un endpoint integro quando le parti più importanti dell'applicazione in realtà hanno esito negativo.Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing. Per altre informazioni, vedere modello di monitoraggio degli endpoint di integrità.For more information, see Health Endpoint Monitoring pattern.

Quando Gestione traffico effettua il failover, per un periodo di tempo i client non riescono a raggiungere l'applicazione.When Traffic Manager fails over there is a period of time when clients cannot reach the application. La durata di questo periodo è influenzata dai fattori seguenti:The duration is affected by the following factors:

  • Il probe di integrità deve rilevare che l'area primaria è diventata irraggiungibile.The health probe must detect that the primary region has become unreachable.

  • I server DNS devono aggiornare i record DNS memorizzati nella cache per l'indirizzo IP, che dipende dalla durata (TTL) DNS.DNS servers must update the cached DNS records for the IP address, which depends on the DNS time-to-live (TTL). Il valore TTL predefinito è di 300 secondi (5 minuti), ma è possibile configurare questo valore durante la creazione del profilo di Gestione traffico.The default TTL is 300 seconds (5 minutes), but you can configure this value when you create the Traffic Manager profile.

Per dettagli, vedere Informazioni sul monitoraggio di Gestione traffico.For details, see About Traffic Manager Monitoring.

Se Gestione traffico effettua il failover, è consigliabile eseguire un failback manuale invece di implementare un failback automatico.If Traffic Manager fails over, we recommend performing a manual failback rather than implementing an automatic failback. In caso contrario, si potrebbe creare una situazione in cui l'applicazione passa alternativamente da un'area all'altra.Otherwise, you can create a situation where the application flips back and forth between regions. Verificare che tutti i sottosistemi dell'applicazione siano integri prima del failback.Verify that all application subsystems are healthy before failing back.

Si noti che Gestione traffico effettua automaticamente il failback per impostazione predefinita.Note that Traffic Manager automatically fails back by default. Per evitare questa situazione, ridurre manualmente la priorità dell'area primaria dopo un evento di failover.To prevent this, manually lower the priority of the primary region after a failover event. Ad esempio, si supponga che l'area primaria sia di priorità 1 e la secondaria di priorità 2.For example, suppose the primary region is priority 1 and the secondary is priority 2. Dopo un failover, impostare l'area primaria sul livello di priorità 3 per evitare il failback automatico.After a failover, set the primary region to priority 3, to prevent automatic failback. Quando si è pronti per cambiare, aggiornare la priorità a 1.When you are ready to switch, back, update the priority to 1.

Il comando seguente dell'interfaccia della riga di comando di Azure aggiorna la priorità:The following Azure CLI command updates the priority:

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:Another approach is to temporarily disable the endpoint until you are ready to fail back:

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.Depending on the cause of a failover, you might need to redeploy the resources within a region. Prima di eseguire nuovamente il failback, eseguire un test della conformità operativa,Before failing back, perform an operational readiness test. che avrà lo scopo di verificare gli elementi seguenti:The test should verify things like:

  • Le macchine virtuali sono configurate correttamenteVMs are configured correctly. (tutto il software richiesto è installato, IIS è in esecuzione e così via).(All required software is installed, IIS is running, and so on.)

  • I sottosistemi dell'applicazione sono integri.Application subsystems are healthy.

  • Test funzionaleFunctional testing. (ad esempio, il livello del database è raggiungibile dal livello Web).(For example, the database tier is reachable from the web tier.)

Configurare i gruppi di disponibilità Always On di SQL ServerConfigure SQL Server Always On Availability Groups

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).Prior to Windows Server 2016, SQL Server Always On Availability Groups require a domain controller, and all nodes in the availability group must be in the same Active Directory (AD) domain.

Per configurare il gruppo di disponibilità:To configure the availability group:

  • Collocare almeno due controller di dominio in ogni area.At a minimum, place two domain controllers in each region.

  • Assegnare a ogni controller di dominio un indirizzo IP statico.Give each domain controller a static IP address.

  • Creare una VPN per abilitare la comunicazione tra due reti virtuali.Create VPN to enable communication between two virtual networks.

  • Per ogni rete virtuale, aggiungere gli indirizzi IP dei controller di dominio (da entrambe le aree) all'elenco dei server DNS.For each virtual network, add the IP addresses of the domain controllers (from both regions) to the DNS server list. È possibile usare il comando dell'interfaccia della riga di comando seguente.You can use the following CLI command. Per altre informazioni, vedere Modificare i server DNS.For more information, see Change DNS servers.

    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.Create a Windows Server Failover Clustering (WSFC) cluster that includes the SQL Server instances in both regions.

  • Creare un gruppo di disponibilità Always On di SQL Server che includa le istanze di SQL Server in entrambe le aree primaria e secondaria.Create a SQL Server Always On Availability Group that includes the SQL Server instances in both the primary and secondary regions. 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)).See Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) for the steps.

    • Inserire la replica primaria nell'area primaria.Put the primary replica in the primary region.

    • Inserire una o più repliche secondarie nell'area primaria.Put one or more secondary replicas in the primary region. Configurarle per l'uso del commit sincrono con il failover automatico.Configure these to use synchronous commit with automatic failover.

    • Inserire una o più repliche secondarie nell'area secondaria.Put one or more secondary replicas in the secondary region. Configurarle per l'uso del commit asincrono per motivi di prestazioniConfigure these to use asynchronous commit, for performance reasons. (in caso contrario, tutte le transazioni T-SQL dovranno attendere l'esecuzione di un round trip in rete all'area secondaria).(Otherwise, all T-SQL transactions have to wait on a round trip over the network to the secondary region.)

Nota

Le repliche con commit asincrono non supportano il failover automatico.Asynchronous commit replicas don't support automatic failover.

Considerazioni sulla disponibilitàAvailability considerations

Con un'app complessa a più livelli, potrebbe non essere necessario replicare l'intera applicazione nell'area secondaria.With a complex N-tier app, you may not need to replicate the entire application in the secondary region. In alternativa, è possibile replicare solo un sottosistema critico indispensabile per supportare la continuità aziendale.Instead, you might just replicate a critical subsystem that is needed to support business continuity.

Gestione traffico è un possibile punto di guasto nel sistema.Traffic Manager is a possible failure point in the system. In caso di interruzione del servizio Gestione traffico, i client non riescono ad accedere all'applicazione durante il tempo di inattività.If the Traffic Manager service fails, clients cannot access your application during the downtime. Esaminare il contratto di Service di gestione trafficoe determinare se l'uso di gestione traffico da solo soddisfa i requisiti aziendali per la disponibilità elevata.Review the Traffic Manager SLA, and determine whether using Traffic Manager alone meets your business requirements for high availability. In caso contrario, provare ad aggiungere un'altra soluzione di gestione del traffico come failback.If not, consider adding another traffic management solution as a 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.If the Azure Traffic Manager service fails, change your CNAME records in DNS to point to the other traffic management service. (questo passaggio deve essere eseguito manualmente e l'applicazione non sarà disponibile finché non vengono propagate le modifiche al DNS).(This step must be performed manually, and your application will be unavailable until the DNS changes are propagated.)

Per il cluster di SQL Server, sono da considerare due scenari di failover:For the SQL Server cluster, there are two failover scenarios to consider:

  • Tutte le repliche del database SQL Server nell'area primaria hanno esito negativo.All of the SQL Server database replicas in the primary region fail. Ad esempio, questo problema potrebbe verificarsi durante un'interruzione a livello di area.For example, this could happen during a regional outage. In questo caso, è necessario effettuare manualmente il failover del gruppo di disponibilità, anche se Gestione traffico effettua il failover automaticamente sul front-end.In that case, you must manually fail over the availability group, even though Traffic Manager automatically fails over on the 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.Follow the steps in Perform a Forced Manual Failover of a SQL Server Availability Group, which describes how to perform a forced failover by using SQL Server Management Studio, Transact-SQL, or PowerShell in SQL Server 2016.

    Avviso

    Con il failover forzato, sussiste il rischio di perdita dei dati.With forced failover, there is a risk of data loss. Quando l'area primaria torna online, eseguire uno snapshot del database e usare tablediff per individuare le differenze.Once the primary region is back online, take a snapshot of the database and use tablediff to find the differences.

  • Gestione traffico effettua il failover all'area secondaria, ma la replica primaria del database SQL Server è ancora disponibile.Traffic Manager fails over to the secondary region, but the primary SQL Server database replica is still available. Ad esempio, nel livello front-end potrebbe verificarsi un errore che non si ripercuote sulle macchine virtuali di SQL Server.For example, the front-end tier might fail, without affecting the SQL Server VMs. In tal caso, il traffico Internet viene indirizzato all'area secondaria e tale area può comunque connettersi alla replica primaria.In that case, Internet traffic is routed to the secondary region, and that region can still connect to the primary replica. Tuttavia, vi sarà un aumento della latenza, poiché le connessioni di SQL Server attraversano le aree geografiche.However, there will be increased latency, because the SQL Server connections are going across regions. In questa situazione è necessario effettuare un failover manuale come indicato di seguito:In this situation, you should perform a manual failover as follows:

    1. Passare temporaneamente una replica del database SQL Server nell'area secondaria al commit sincrono,Temporarily switch a SQL Server database replica in the secondary region to synchronous commit. in modo da garantire che non si verifichino perdite di dati durante il failover.This ensures there won't be data loss during the failover.

    2. Effettuare il failover a tale replica.Fail over to that replica.

    3. Quando si effettua il failback all'area primaria, ripristinare l'impostazione di commit asincrono.When you fail back to the primary region, restore the asynchronous commit setting.

Considerazioni sulla gestibilitàManageability considerations

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.When you update your deployment, update one region at a time to reduce the chance of a global failure from an incorrect configuration or an error in the application.

Testare la resilienza del sistema agli errori.Test the resiliency of the system to failures. Di seguito sono riportati alcuni scenari di errore comuni da testare:Here are some common failure scenarios to test:

  • Arrestare le istanze di macchina virtuale.Shut down VM instances.

  • Esercitare un uso elevato delle risorse come CPU e memoria.Pressure resources such as CPU and memory.

  • Disconnettere/ritardare la rete.Disconnect/delay network.

  • Arrestare in modo anomalo i processi.Crash processes.

  • Far scadere i certificati.Expire certificates.

  • Simulare errori hardware.Simulate hardware faults.

  • Arrestare il servizio DNS nei controller di dominio.Shut down the DNS service on the domain controllers.

Misurare i tempi di ripristino e verificare che soddisfino i requisiti aziendali.Measure the recovery times and verify they meet your business requirements. Testare anche le combinazioni di modalità di errore.Test combinations of failure modes, as well.

Passaggi successiviNext steps