Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo contiene informazioni dettagliate sulla resilienza a livello di area con il supporto per le zone di disponibilità e il ripristino di emergenza tra aree di continuità aziendale per Azure Spring Apps.
Supporto della zona di disponibilità
Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.
Azure Spring Apps supporta la ridondanza della zona. Quando si crea un'istanza del servizio Azure Spring Apps con la ridondanza della zona abilitata, Azure Spring Apps distribuisce automaticamente le risorse fondamentali su tutte le sezioni logiche dell'infrastruttura di Azure sottostante. La risorsa di calcolo sottostante distribuisce le macchine virtuali in tutte le zone di disponibilità per garantire la possibilità di calcolare. La risorsa di archiviazione sottostante replica i dati sulle zone di disponibilità in modo che siano disponibili anche in caso di errori del data center. Questa distribuzione offre un livello di disponibilità superiore e protegge in caso di errori hardware o di eventi di manutenzione pianificata.
Prerequisiti
La ridondanza della zona non è disponibile nel piano Basic.
Azure Spring Apps supporta le zone di disponibilità nelle seguenti aree geografiche:
- Australia East
- Brasile meridionale
- Canada Central
- Central US
- East Asia
- East US
- Stati Uniti orientali 2
- Francia centrale
- Germania centro-occidentale
- North Europe
- Japan East
- Korea Central
- Sudafrica settentrionale
- Stati Uniti centro-meridionali
- Sud-est asiatico
- UK South
- West Europe
- West US 2 (Regione Ovest degli Stati Uniti 2)
- Stati Uniti occidentali 3
Creare un'istanza di Azure Spring Apps con zone di disponibilità abilitate
Annotazioni
È possibile abilitare la ridondanza della zona solo quando si crea l'istanza del servizio Azure Spring Apps. Non è possibile modificare la proprietà di ridondanza della zona dopo la creazione.
È possibile abilitare la ridondanza della zona in Azure Spring Apps usando l'interfaccia della riga di comando di Azure o il portale di Azure.
Per creare un servizio in Azure Spring Apps con la ridondanza della zona abilitata tramite l'interfaccia della riga di comando di Azure, quando si crea il servizio, includere il parametro --zone-redundant, come illustrato nell'esempio seguente:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Abilitare la propria risorsa con le zone di disponibilità abilitate
È possibile abilitare la propria risorsa in Azure Spring Apps, ad esempio l'archiviazione permanente. Tuttavia, è necessario assicurarsi di abilitare la ridondanza della zona per la risorsa. Per altre informazioni, vedere Come abilitare l'archiviazione permanente in Azure Spring Apps.
Esperienza di inattività della zona
Quando un'istanza dell'app ha esito negativo perché si trova in un nodo della macchina virtuale di una zona non riuscita, Azure Spring Apps crea una nuova istanza dell'app per l'app non riuscita in un altro nodo della macchina virtuale di un'altra zona di disponibilità. Gli utenti possono riscontrare una breve interruzione durante questa operazione. Non è necessaria alcuna azione da parte dell'utente, e l'istanza di Azure Spring Apps interessata verrà ripristinata dal servizio.
Pricing
Non sono previsti costi aggiuntivi associati all'abilitazione della ridondanza della zona. È sufficiente effettuare il pagamento per il piano Standard o Enterprise, necessario per abilitare la ridondanza della zona.
Ripristino di emergenza e continuità aziendale tra aree
Il ripristino di emergenza si riferisce alle procedure usate dalle organizzazioni per il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a creare il piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Per il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In questo modello Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Tuttavia, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili della configurazione di un piano di ripristino di emergenza adeguato alle vostre esigenze operative. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e indicazioni per supportare il ripristino di emergenza. È possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per sviluppare il piano di ripristino di emergenza.
Il servizio Azure Spring Apps non fornisce il ripristino di emergenza geografico, ma un'attenta pianificazione consente di evitare tempi di inattività.
Per garantire la disponibilità elevata e la protezione in caso di emergenza, distribuire le applicazioni ospitate in Azure Spring Apps su più aree geografiche. Azure fornisce un elenco di aree associate per consentire la pianificazione delle distribuzioni delle app di conseguenza.
Quando si progetta l'architettura, tenere presenti i fattori chiave seguenti:
- Disponibilità a livello di area. Per ridurre al minimo i tempi di trasmissione e i ritardi della rete, scegliere un'area che supporta la ridondanza della zona di Azure Spring Apps o un'area geografica vicina agli utenti.
- Aree associate di Azure. Per garantire il coordinamento degli aggiornamenti della piattaforma e l'assegnazione di priorità alle attività di ripristino, se necessario, scegliere le aree abbinate all'interno dell'area geografica scelta.
- Disponibilità del servizio. decidere se l'esecuzione delle aree associate deve essere ad accesso molto frequente/molto frequente, ad accesso molto frequente/frequente, ad accesso molto frequente/sporadico.
Usare Gestione traffico di Microsoft Azure per indirizzare il traffico
Gestione traffico di Azure offre funzioni di bilanciamento del carico del traffico basato su DNS ed è in grado di distribuire il traffico di rete su più aree. Usare Gestione traffico di Azure per indirizzare i clienti all'istanza del servizio Azure Spring Apps più vicina. Per prestazioni e ridondanza ottimali, indirizzare tutto il traffico delle applicazioni attraverso Gestione traffico di Azure prima di inviarlo all'istanza del servizio Azure Spring Apps. Per altre informazioni, vedere Gestione traffico di Azure.
Se si dispone di applicazioni in Azure Spring Apps in esecuzione in più aree, Gestione traffico di Azure può controllare il flusso del traffico verso le applicazioni di ognuna di esse. Definire un endpoint di Gestione traffico di Azure per ogni istanza del servizio usando l'IP dell'istanza. È necessario connettersi a un nome DNS di Gestione traffico di Azure che punta all'istanza del servizio Azure Spring Apps. Gestione traffico di Azure esegue il bilanciamento del carico del traffico tra gli endpoint definiti. Se un'emergenza colpisce un data center, Gestione traffico di Azure indirizza il traffico dall'area interessata all'area associata, garantendo la continuità del servizio.
Usare la procedura seguente per creare un'istanza di Gestione traffico di Azure per le istanze di Azure Spring Apps:
Creare istanze di Azure Spring Apps in due aree diverse. Ad esempio, creare istanze del servizio negli Stati Uniti orientali e nell'Europa occidentale, come illustrato nella tabella seguente. Ogni istanza funge da endpoint primario e di failover per il traffico.
Nome del servizio Posizione Applicazione service-sample-a East US gateway/auth-service/account-service esempio-di-servizio-b West Europe gateway/auth-service/account-service Configurare un dominio personalizzato per le istanze del servizio. Per altre informazioni, vedere Esercitazione: Eseguire il mapping di un dominio personalizzato esistente ad Azure Spring Apps. Al termine della configurazione, entrambe le istanze del servizio verranno associate allo stesso dominio personalizzato, ad esempio
bcdr-test.contoso.com.Creare una gestione traffico e due endpoint. Per istruzioni, vedere Avvio rapido: Creare un profilo di Gestione traffico usando il portale di Azure, ottenendo il seguente profilo di Gestione traffico:
- Nome DNS di Gestione traffico:
http://asa-bcdr.trafficmanager.net - Profili endpoint:
Profile TIPO Obiettivo Priority Impostazioni intestazione personalizzata Profilo endpoint A Endpoint esterno service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comProfilo endpoint B Endpoint esterno service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Nome DNS di Gestione traffico:
Creare un record CNAME in una zona DNS simile all'esempio seguente:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
L'ambiente è ora configurato. Se sono stati usati i valori di esempio degli articoli collegati, si dovrebbe essere in grado di accedere all'app usando https://bcdr-test.contoso.com.
Usare Frontdoor di Azure e il gateway applicazione di Azure per instradare il traffico
Frontdoor di Azure è un punto di ingresso globale e scalabile che usa la rete perimetrale globale Microsoft per creare applicazioni Web veloci, sicure e ampiamente scalabili. Frontdoor di Azure offre la stessa ridondanza multi-geografica e il routing verso l'area più vicina di Gestione traffico di Azure. Frontdoor di Azure offre inoltre funzionalità avanzate, ad esempio la terminazione del protocollo TLS, l'elaborazione a livello di applicazione e il Web application firewall (WAF). Per altre informazioni, vedere Che cos'è Frontdoor di Azure?
Il diagramma seguente illustra l'architettura di un'istanza del servizio Azure Spring Apps integrata nella rete virtuale, con ridondanza su più aree. Il diagramma mostra la configurazione corretta del proxy inverso per gateway applicazione e Frontdoor con un dominio personalizzato. Questa architettura si basa sullo scenario descritto in Esporre applicazioni con TLS end-to-end in una rete virtuale. Questo approccio combina due istanze di Azure Spring Apps integrate nel gateway applicazione in un'istanza con ridondanza geografica.
