Esporta (0) Stampa
Espandi tutto

Ripristino di emergenza e disponibilità elevata per applicazioni Azure

Aggiornamento: aprile 2014

Autori principali: Michael McKeown, Cloud Solutions Architect (Aditi); Hanu Kommalapati, Principal Technology Evangelist (Microsoft)

Collaboratore: Jason Roth

Revisori: Patrick Wickline, Dennis Mulder, Steve Howard, Tim Wieman, James Podgorski, Ryan Berry, Shweta Gupta, Harry Chen, Jim Blanchard, Andy Roberts, Christian Els

Questo articolo è incentrato sulla disponibilità elevata per applicazioni eseguite in Azure. In una strategia generale per la disponibilità elevata è prevista anche l'area del ripristino di emergenza. Nei piani predisposti per gli errori e le emergenze nel cloud sono necessarie la capacità di rilevare rapidamente i problemi e l'implementazione di una strategia adeguata al massimo tempo di inattività delle applicazioni accettabile. È inoltre necessario tenere conto della misura in cui è ammissibile la perdita di dati dell'applicazione senza effetti negativi sulle attività aziendali in seguito al ripristino.

Quando chiediamo ai clienti se sono preparati a problemi temporanei e su larga scala, la maggior parte di essi dichiara di esserlo. Prima di rispondere, tuttavia, occorrerebbe domandarsi se la propria società sperimenta questi scenari problematici, se testa il ripristino dei database per accertarsi di disporre dei processi corretti. È probabile che non sia così. Ciò accade perché ai fini di un corretto ripristino di emergenza è necessario pianificare e progettare con estrema cura l'implementazione dei processi adeguati. Analogamente a quanto avviene per molti altri requisiti non funzionali, ad esempio la sicurezza, raramente si dedicano al ripristino di emergenza il tempo e le attività di analisi preliminari effettivamente necessari. La maggior parte dei clienti, inoltre, non dispone di budget sufficienti per dotarsi di data center dislocati in aree geografiche diverse e con capacità ridondante. Di conseguenza, perfino le applicazioni cruciali vengono spesso escluse da un'accurata pianificazione del ripristino di emergenza.

Le piattaforme cloud, come Azure, forniscono data center collocati in diverse parti del mondo. Queste piattaforme offrono inoltre caratteristiche a supporto della disponibilità e di diversi scenari di ripristino di emergenza. È quindi possibile tenere nell'opportuna considerazione tutte le applicazioni cloud cruciali per realizzare un sistema a prova di emergenza. Azure offre resilienza e funzionalità di ripristino di emergenza integrate in molti dei suoi servizi. Le funzionalità della piattaforma devono essere accuratamente esaminate e corredate di strategie applicative.

In questo white paper vengono illustrate le fasi di progettazione necessarie per una distribuzione di Azure a prova di emergenza, in modo da poter implementare un più ampio processo per la continuità aziendale. I piani per la continuità aziendale sono roadmap concepite per assicurare la continuità delle attività in condizioni avverse. Tali condizioni possono essere rappresentate da errori della tecnologia, ad esempio la disconnessione di un servizio, oppure da calamità naturali come tempeste o interruzioni di energia. La resilienza delle applicazioni in caso di emergenze rappresenta solo una parte del più ampio processo di ripristino di emergenza descritto in questa guida ai piani di emergenza per i sistemi IT del NIST.

Nelle sezioni seguenti vengono definiti diversi livelli di problemi, le tecniche con cui affrontarli e le architetture che supportano tali tecniche. Queste informazioni consentono di approfondire gli aspetti dei processi e delle procedure di ripristino di emergenza allo scopo di accertarsi che la propria strategia risulti corretta ed efficiente.

Un'applicazione ben strutturata è in grado di resistere a problemi funzionali a livello tattico nonché di tollerare errori di sistema strategici a livello di data center. Nelle sezioni seguenti viene definita la terminologia a cui si fa riferimento nel documento per descrivere diversi aspetti dei servizi cloud resilienti.

Le applicazioni cloud a disponibilità elevata implementano strategie in grado di attenuare l'effetto prodotto dall'indisponibilità di dipendenze, quali i servizi gestiti offerti dalla piattaforma cloud. Nonostante i possibili problemi delle funzionalità della piattaforma cloud, questo approccio consente all'applicazione di continuare a fornire le caratteristiche di sistema previste a livello funzionale e non funzionale. Questo aspetto è illustrato in dettaglio nell'articolo Operatore alternativo: informazioni aggiuntive per architetture cloud resilienti.

Quando si implementa l'applicazione è necessario considerare la possibilità che si verifichi una carenza di capacità. È inoltre necessario tenere conto dell'impatto di un problema di questo tipo sull'applicazione dal punto di vista delle attività aziendali prima di approfondire le strategie di implementazione. Se non si valutano con attenzione l'impatto aziendale e la probabilità che si verifichino condizioni di rischio, l'implementazione può rivelarsi costosa e potenzialmente inutile.

Per comprendere questo aspetto correlato alla disponibilità elevata, è possibile ricorrere a un'analogia automobilistica. Perfino i componenti di migliore qualità e una meccanica eccellente non possono impedire guasti occasionali. In presenza di gomme lisce, ad esempio, il veicolo continua ad andare ma le prestazioni risultano ridotte. Se si è tenuto conto in anticipo di questa eventualità, è possibile utilizzare un ruotino di scorta finché non si raggiunge un'officina. Sebbene questa soluzione non consenta di tenere velocità elevate, è comunque possibile continuare a condurre il veicolo finché non si provvede a sostituire lo pneumatico. Analogamente, pianificando una potenziale perdita di capacità in un servizio cloud è possibile evitare che un problema relativamente minore provochi l'indisponibilità dell'intera applicazione. Ciò vale anche se il servizio cloud deve essere eseguito con funzionalità ridotte.

La disponibilità elevata per i servizi cloud include alcune caratteristiche chiave, ovvero disponibilità, scalabilità e tolleranza di errore. Sebbene queste caratteristiche siano correlate tra loro, è importante comprenderne gli aspetti specifici e il modo in cui contribuiscono alla disponibilità generale della soluzione.

Un'applicazione disponibile tiene conto della disponibilità dell'infrastruttura sottostante e dei servizi dipendenti. Le applicazioni disponibili rimuovono i singoli punti di errore grazie alla ridondanza e a una progettazione resiliente. Quando parliamo di disponibilità in Azure, è importante comprendere il concetto di disponibilità effettiva della piattaforma. La disponibilità effettiva si basa sui contratti di servizio di ogni servizio dipendente e sul relativo effetto cumulativo rispetto alla disponibilità complessiva del sistema.

La disponibilità del sistema si misura in base alla percentuale di una data finestra temporale per cui il sistema risulta in grado di funzionare. Ad esempio, il contratto di servizio sulla disponibilità di almeno due istanze di un ruolo Web o di lavoro in Azure è pari al 99,95%. Questo valore non misura i livelli di prestazioni o funzionalità dei servizi eseguiti nei ruoli. Tuttavia, la disponibilità effettiva di un servizio cloud dipende anche dai vari contratti di servizio degli altri servizi dipendenti. Maggiore è il numero di componenti mobili nel sistema, maggiore è l'attenzione da dedicare alla verifica che l'applicazione sia in grado di soddisfare in modo resiliente i requisiti di disponibilità degli utenti finali.

Verranno ora esaminati i contratti di servizio seguenti che utilizzano i servizi di Azure Calcolo, Database SQL di Azure e Archiviazione di Azure.

 

Servizio di Azure Contratto di servizio Potenziale inattività (in minuti)/mese (30 giorni)

Calcolo

99.95%

21.6

Database SQL

99.90%

43.2

Archiviazione

99.90%

43.2

È necessario che la pianificazione tenga conto della possibilità che i servizi diventino non disponibili in momenti diversi. In questo esempio semplificato, il numero totale di minuti al mese in cui l'applicazione potrebbe essere inattiva è pari a 108. Un mese di 30 giorni è costituito da un totale di 43.200 minuti. 108 minuti rappresentano una percentuale pari allo 0,25% del numero totale di minuti in un mese di 30 giorni (43.200 minuti). Questo valore implica una disponibilità effettiva del 99,75% per il servizio cloud.

L'utilizzo delle tecniche per la disponibilità descritte in questo documento può tuttavia migliorare questa soglia. Se ad esempio si progetta l'applicazione affinché continui a essere eseguita in caso di indisponibilità del database SQL; è possibile rimuovere questa voce dall'equazione. Ciò potrebbe implicare un'esecuzione con funzionalità ridotte dell'applicazione, pertanto è necessario tenere conto anche dei requisiti aziendali. Per un elenco completo dei contratti di servizio di Azure, vedere Contratti di servizio.

La scalabilità influisce direttamente sulla disponibilità, in quanto un'applicazione che smette di funzionare a causa dell'aumento del carico non risulta più disponibile. Le applicazioni scalabili sono quelle in grado di soddisfare un aumento delle richieste con risultati coerenti in tempi accettabili. I sistemi di questo tipo possono essere scalati in senso orizzontale o verticale allo scopo di gestire un carico maggiore continuando ad assicurare prestazioni coerenti. In termini semplici, la scalabilità orizzontale consiste nell'aggiunta di un maggior numero di computer delle stesse dimensioni in termini di processore, memoria e larghezza di banda, mentre quella verticale nell'aumento delle dimensioni dei computer esistenti. Per Azure sono disponibili opzioni di scalabilità verticale per la selezione di computer di diverse dimensioni per il calcolo. La modifica delle dimensioni di un computer ne implica tuttavia la ridistribuzione. Pertanto, le soluzioni più flessibili sono quelle progettate per la scalabilità orizzontale. Ciò è particolarmente vero per il calcolo, in quanto è possibile aumentare facilmente il numero di istanze in esecuzione di qualsiasi ruolo Web o di lavoro. Tali istanze aggiuntive gestiscono l'aumento del traffico tramite il portale Web di Azure, script di PowerShell o il codice. Questa decisione deve basarsi sugli aumenti rilevati nelle specifiche metriche sottoposte a monitoraggio. In questo scenario le metriche o le prestazioni correlate agli utenti non subiscono un calo apprezzabile sotto carico. In genere, i ruoli Web e di lavoro archiviano gli stati all'esterno. Questo consente di bilanciare il carico in modo flessibile e di gestire automaticamente eventuali modifiche al numero totale di istanze. La scalabilità orizzontale è utile anche con i servizi, ad esempio quello di archiviazione di Azure, per i quali non sono disponibili opzioni multilivello per la scalabilità verticale.

Le distribuzioni cloud dovrebbero essere considerate come raccolte di unità di scala. Ciò conferisce elasticità all'applicazione nel soddisfare i livelli di velocità effettiva richiesti dagli utenti finali. Le unità di scala sono più semplici da visualizzare a livello di server Web o applicazioni, in quanto Azure offre già nodi di calcolo senza stato tramite i ruoli Web e di lavoro. L'aggiunta di più unità di scala di calcolo alla distribuzione non determina effetti collaterali in termini di gestione degli stati, in quanto le unità di scala di calcolo sono senza stato. Le unità di scala dell'archiviazione sono responsabili della gestione di una partizione di dati strutturati o non strutturati. Esempi di unità di scala di archiviazione includono la partizione delle tabelle di Azure, il contenitore di BLOB e il database SQL. Anche l'uso di più account di archiviazione di Azure influisce direttamente sulla scalabilità dell'applicazione. Un servizio cloud altamente scalabile deve essere progettato in modo da integrare più unità di scala di archiviazione. Se ad esempio un'applicazione utilizza dati relazionali, i dati vanno partizionati tra diversi database SQL. In questo modo l'archiviazione potrà adattarsi al modello elastico delle unità di scala di calcolo. Analogamente, l'archiviazione di Azure consente schemi di partizionamento dei dati che richiedono una progettazione mirata a soddisfare le esigenze di velocità effettiva del livello di calcolo. Per un elenco di procedure consigliate relative alla progettazione di servizi cloud scalabili, vedere Procedure consigliate per la progettazione di servizi su larga scala nei servizi cloud di Azure.

Le applicazioni devono presupporre che ogni funzionalità dipendente del cloud possa prima o poi risultare non disponibile. Le applicazioni con tolleranza di errore rilevano gli elementi con problemi e agiscono in modo da continuare a funzionare e restituire risultati coerenti durante un periodo di tempo specifico. Per le condizioni di errore temporanee, i sistemi con tolleranza di errore si avvalgono di criteri di ripetizione dei tentativi. Per gli errori più gravi, l'applicazione è in grado di rilevare i problemi ed eseguire il failover su hardware alternativo o ricorrere a piani di emergenza finché l'errore non viene risolto. Le applicazioni più affidabili riescono a gestire correttamente gli errori di uno o più componenti senza smettere di funzionare correttamente. Le applicazioni con tolleranza di errore possono adottare una o più strategie di progettazione, ad esempio la ridondanza, la replica o la riduzione delle funzionalità.

Le distribuzioni cloud possono smettere di funzionare a causa di interruzioni sistemiche dei servizi dipendenti o dell'infrastruttura sottostante. In tali circostanze, i piani per la continuità aziendale prevedono l'attivazione del processo di ripristino di emergenza. Questo processo in genere include sia procedure automatizzate sia interventi del personale operativo allo scopo di riattivare l'applicazione in un data center funzionante. Ciò implica il trasferimento di utenti, dati e servizi dell'applicazione al nuovo data center. Prevede inoltre l'utilizzo di supporti di backup o di una replica continua.

Torniamo al paragone precedente tra la disponibilità elevata e la capacità di risolvere il problema di uno pneumatico liscio grazie a un ruotino di scorta. Il ripristino di emergenza è invece paragonabile alle misure che si adottano in seguito a un tamponamento a causa del quale il veicolo risulta inutilizzabile. In questo caso, la soluzione migliore consiste nell'individuare un modo efficiente per cambiare mezzo, ad esempio rivolgendosi a un servizio di trasporto o a un amico. In uno scenario di questo tipo, è probabile che occorra più tempo per rimettersi in viaggio e che risulti più complesso ripristinare e riparare il veicolo originale. Analogamente, il ripristino di emergenza in un altro data center rappresenta un'attività complessa che implica in genere un certo tempo di inattività e potenziali perdite di dati. Per comprendere e valutare meglio le strategie di ripristino di emergenza, è importante definire due termini, ovvero l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO).

L'obiettivo del tempo di ripristino corrisponde alla quantità di tempo massima allocata per il ripristino delle funzionalità dell'applicazione. Questo valore si basa sui requisiti aziendali ed è correlato all'importanza dell'applicazione. Le applicazioni aziendali critiche richiedono un RTO basso.

L'obiettivo del punto di ripristino corrisponde alla finestra temporale ammissibile di dati persi a causa del processo di ripristino. Se ad esempio l'RPO è pari a un'ora, è necessario eseguire il backup o la replica completa di tutti i dati almeno ogni ora. Dopo il trasferimento dell'applicazione in un data center alternativo, nel backup può mancare al massimo un'ora di dati. Come per lo RTO, le applicazioni critiche richiedono un RPO ridotto.

Le applicazioni a disponibilità elevata sono quelle in grado di attutire gli effetti delle fluttuazioni correlate alla disponibilità, al carico e agli errori temporanei dei servizi dipendenti e dell'hardware. L'applicazione continua a funzionare con prestazioni accettabili a livello di sistema e utenti, come definito dai requisiti aziendali o dai contratti di servizio.

La piattaforma Azure offre numerose funzionalità integrate a supporto delle applicazioni a disponibilità elevata. In questa sezione sono illustrate alcune delle funzionalità principali. Per un'analisi più completa della piattaforma, vedere Informazioni tecniche sulla continuità aziendale di Azure.

Il controller di infrastruttura (FC) di Azure è responsabile del provisioning e del monitoraggio della condizione delle istanze di calcolo di Azure. Il controller di infrastruttura verifica lo stato dell'hardware e del software delle istanze dei computer host e guest. Quando viene rilevato un errore, i contratti di servizio vengono applicati rilocando automaticamente le istanze delle macchine virtuali. I contratti di servizio relativi al calcolo sono inoltre supportati dai concetti di dominio di errore e dominio di aggiornamento.

Per la distribuzione di più istanze di ruolo in Azure vengono utilizzati diversi domini di errore. Il limite di un dominio di errore è sostanzialmente un altro rack hardware nello stesso data center. I domini di errore consentono di ridurre la probabilità che un errore hardware localizzato interrompa il funzionamento di un'applicazione. Non è possibile gestire il numero di domini di errore allocati ai propri ruoli di lavoro e Web. Il controller di infrastruttura utilizza risorse dedicate distinte da quelle delle applicazioni ospitate di Azure. Assicura un tempo di attività pari al 100% in quanto costituisce il nucleo del sistema Azure. Monitora e gestisce le istanze dei ruoli tra i domini di errore. Nel diagramma seguente sono illustrate le risorse condivise di Azure distribuite e gestite dal controller di infrastruttura nei diversi domini di errore.

Figura 1. Isolamento dei domini di errore (visualizzazione semplificata)

I domini di aggiornamento sono analoghi a quelli di errore sotto il profilo del funzionamento, tuttavia supportano gli aggiornamenti anziché gli errori. Un dominio di aggiornamento è un'unità logica di separazione delle istanze che determina quali istanze di un determinato servizio verranno aggiornate in un dato momento. Per impostazione predefinita, per una distribuzione di servizi ospitati vengono definiti cinque domini di aggiornamento, ma è possibile modificare questo valore nel file di definizione del servizio. Ad esempio, se si dispone di otto istanze di un ruolo Web saranno disponibili due istanze in tre domini di aggiornamento e due istanze in un dominio di aggiornamento. La sequenza di aggiornamento è definita da Azure, ma è basata sul numero di domini di aggiornamento. Per altre informazioni sui domini di aggiornamento, vedere Aggiornare un servizio di Azure.

Oltre a queste funzionalità della piattaforma a supporto della disponibilità elevata delle risorse di calcolo, Azure include funzionalità aggiuntive di disponibilità elevata per altri servizi. Il servizio di archiviazione di Azure gestisce ad esempio tre repliche di tutti i dati di BLOB, tabelle e code. Prevede inoltre l'opzione di replica geografica per archiviare backup di BLOB e tabelle in un data center secondario. La rete per la distribuzione di contenuti (CDN) consente di memorizzare nella cache i BLOB in diverse parti del mondo a fini di ridondanza e di scalabilità. Il servizio database SQL di Azure gestisce più repliche. Oltre all'articolo Informazioni tecniche sulla continuità aziendale di Azure, vedere Procedure consigliate per la progettazione di servizi su larga scala nei servizi cloud di Azure per una trattazione completa delle funzionalità di disponibilità della piattaforma.

Sebbene Azure includa diverse funzionalità per supportare la disponibilità elevata, è importante comprenderne le limitazioni. Per quanto riguarda il calcolo, Azure garantisce la disponibilità e il funzionamento dei ruoli, ma non è in grado di rilevare se l'applicazione è in esecuzione o in sovraccarico. Per il database SQL di Azure, i dati vengono replicati in modo sincrono nel data center. Le repliche dei database non sono backup temporizzati. Per quanto concerne l'archiviazione di Azure, dati di tabelle e BLOB vengono replicati per impostazione predefinita in un data center alternativo, tuttavia non è possibile accedere alle repliche finché Microsoft non decide il failover sul sito alternativo. Il failover di un data center si verifica in genere solo in caso di interruzioni prolungate di un intero data center e non sono previsti contratti di servizio per quanto concerne il tempo di failover geo. È inoltre importante notare che eventuali danneggiamenti dei dati si diffondono rapidamente alle repliche. Per questi motivi, è necessario corredare le funzionalità di disponibilità della piattaforma con funzionalità di disponibilità specifiche dell'applicazione, ad esempio una funzionalità di snapshot dei BLOB per creare backup temporizzati dei dati.

Per la maggior parte, questo articolo è incentrato sui servizi cloud che si avvalgono del modello di piattaforma distribuita come servizio (PaaS, Platform as a Service). Esistono tuttavia specifiche funzionalità di disponibilità per le macchine virtuali di Azure che utilizzano il modello di infrastruttura distribuita come servizio (IaaS, Infrastructure as a Service). Allo scopo di garantire disponibilità elevata delle macchine virtuali, è necessario utilizzare i set di disponibilità. In termini di funzionalità, i set di disponibilità sono analoghi ai domini di errore e di aggiornamento. Azure inserisce le macchine virtuali nei set di disponibilità in modo da impedire che problemi hardware localizzati e attività di manutenzione determinino l'indisponibilità di tutti i computer di un gruppo. I set di disponibilità sono necessari per il rispetto del contratto di servizio di Azure relativo alla disponibilità delle macchine virtuali. Per altre informazioni, vedere la pagina relativa alla gestione della disponibilità delle macchine virtuali (la pagina potrebbe essere in inglese). Nel diagramma seguente è illustrata una rappresentazione dei due set di disponibilità in cui sono rispettivamente raggruppate le macchine virtuali Web e di SQL Server.

Figura 2. Set di disponibilità per le macchine virtuali di Azure

Si noti che nel diagramma precedente, SQL Server è installato ed eseguito nella macchine virtuali. Questa circostanza è diversa rispetto alla trattazione precedente del database SQL di Azure che invece offre il database come servizio gestito.

La maggior parte delle strategie per la disponibilità elevata prevede la ridondanza o la rimozione di dipendenze rigide tra i componenti delle applicazioni. La progettazione dell'applicazione deve supportare la tolleranza di errore durante tempi di inattività sporadici dei servizi di Azure o di terze parti. Nelle sezioni seguenti vengono descritti diversi modelli di applicazione per aumentare la disponibilità dei servizi cloud.

Per aumentare la disponibilità nelle applicazioni Azure è possibile prendere in considerazione le comunicazioni asincrone tra servizi a regime di controllo libero ("loosely-coupled"). In questo modello, scrivere i messaggi nelle code di archiviazione o nelle code di Service Bus perché vengano elaborate in un secondo momento. Quando si scrive il messaggio nella coda, il controllo viene immediatamente restituito al mittente. L'elaborazione del messaggio viene gestita da un altro livello dell'applicazione, in genere implementato come ruolo di lavoro. Se il ruolo di lavoro risulta non disponibile, i messaggi si accumulano nella coda finché il servizio di elaborazione non viene ripristinato. Finché la coda è disponibile, non esiste alcuna dipendenza diretta tra il mittente front-end e il componente di elaborazione del messaggio. In questo modo si elimina il requisito delle chiamate di servizio sincrone che possono rappresentare un collo di bottiglia della velocità effettiva nelle applicazioni distribuite.

Una variante di questa soluzione prevede l'utilizzo del servizio di archiviazione di Azure (BLOB, tabelle, code) o delle code di Service Bus come posizione di failover per chiamate di database non riuscite. Se ad esempio una chiamata sincrona di un'applicazione a un altro servizio, ad esempio al database SQL di Azure, ha ripetutamente esito negativo, potrebbe essere possibile serializzare i dati in una risorsa di archiviazione durevole. Successivamente, quando il servizio o il database torna online, l'applicazione può inviare di nuovo la richiesta dalla risorsa di archiviazione. La differenza in questo modello consiste nel fatto che la posizione intermedia non è una parte costante del flusso di lavoro dell'applicazione. Viene utilizzata solo negli scenari di errore.

In entrambi gli scenari, la comunicazione asincrona e l'archiviazione intermedia impediscono che un servizio back-end inattivo comprometta il funzionamento dell'intera applicazione. Le code fungono da intermediario logico. Per altre indicazioni sulla scelta del servizio di accodamento corretto, vedere Code di Azure e Azure Service Bus: confronto e contrapposizioni.

Un aspetto essenziale nella progettazione di applicazioni a disponibilità elevata consiste nell'utilizzo di una logica di ripetizione dei tentativi per la gestione automatica di un servizio temporaneamente inattivo. Il blocco di applicazioni per la gestione degli errori temporanei, sviluppato dal team Microsoft Patterns and Practices, agevola gli sviluppatori di applicazioni in questo processo. L'aggettivo "temporaneo" indica una condizione temporanea che persiste per un periodo di tempo relativamente breve. Nel contesto di questo articolo, la gestione degli errori temporanei fa parte dello sviluppo di un'applicazione a disponibilità elevata. Esempi di condizioni temporanee sono gli errori di rete intermittenti e la perdita di connessioni di database.

Il blocco applicazione per la gestione degli errori temporanei è un modo semplificato per gestire correttamente gli errori nel codice. Consente di migliorare la disponibilità delle applicazioni aggiungendo un'affidabile logica di gestione degli errori temporanei. Nella maggior parte dei casi la logica della ripetizione dei tentativi gestisce brevi interruzioni riconnettendo mittente e destinatario dopo uno o più tentativi non riusciti. La riuscita del tentativo in genere non viene notata dagli utenti dell'applicazione.

Gli sviluppatori dispongono di tre opzioni per gestire la logica di ripetizione dei tentativi: incrementale, a intervalli fissi ed esponenziale. La modalità incrementale attende un tempo progressivamente maggiore prima di ogni tentativo successivo (ad esempio 1, 2, 3 e 4 secondi). L'opzione a intervalli fissi attende sempre la stessa quantità di tempo tra un tentativo e l'altro (ad esempio 2 secondi). Più casuale, l'opzione esponenziale prevede un'attesa esponenzialmente più lunga a ogni nuovo tentativo (ad esempio 2, 4, 8 e 16 secondi).

La strategia generale nel codice è la seguente:

  1. Definire la strategia e i criteri di ripetizione dei tentativi

  2. Provare l'operazione che potrebbe causare un errore temporaneo.

  3. Se si verifica un errore temporaneo, richiamare il criterio di ripetizione

  4. Se tutti i tentativi hanno esito negativo, generare un'eccezione finale

Testare la logica di ripetizione dei tentativi con errori simulati in modo da accertarsi che i nuovi tentativi sulle operazioni successive non causino un ritardo imprevisto prima di abbandonare l'attività complessiva.

I dati di riferimento sono dati di sola lettura di un'applicazione. Forniscono un contesto aziendale entro cui l'applicazione genera i dati transazionali durante l'esecuzione di un'operazione aziendale. I dati transazionali sono funzioni temporizzate dei dati di riferimento, pertanto la loro integrità dipende dallo snapshot dei dati di riferimento al momento della transazione. Si tratta di una definizione approssimativa, ma dovrebbe essere sufficiente ai fini di questo discorso.

I dati di riferimento nel contesto di un'applicazione sono necessari per il funzionamento di quest'ultima. Vengono creati e gestiti dalle rispettive applicazioni, spesso dai sistemi di gestione dati master. Questi sistemi sono responsabili del ciclo di vita dei dati di riferimento. Esempi di dati di riferimento includono cataloghi di prodotti, anagrafiche dei dipendenti, anagrafiche di parti e di attrezzature. I dati di riferimento possono anche essere creati all'esterno dell'organizzazione, come nel caso dei codici postali o delle aliquote fiscali. Le strategie per aumentare la disponibilità dei dati di riferimento sono in genere meno complesse di quelle per i dati transazionali. I dati di riferimento presentano il vantaggio di essere in genere non soggetti a modifiche.

I ruoli Web e di lavoro di Azure che utilizzano dati di riferimento possono essere resi autonomi in fase di esecuzione distribuendo i dati in questione insieme all'applicazione. Se le dimensioni dell'archivio locale consentono questo tipo di distribuzione, si tratta della situazione ideale. L'uso di database incorporati (SQL o NOSQL) o file XML distribuiti nel file system locale consentirà di rendere autonome le unità di scala di calcolo di Azure. È tuttavia necessario disporre di un meccanismo per aggiornare i dati in ogni ruolo senza bisogno di ripetere la distribuzione. A tale scopo, inserire eventuali aggiornamenti ai dati di riferimento in un endpoint di archiviazione cloud (ad esempio l'archiviazione BLOB o il database SQL di Azure). Aggiungere a ogni ruolo il codice necessario per scaricare gli aggiornamenti dei dati nei nodi di calcolo all'avvio. In alternativa, aggiungere codice che consenta a un amministratore di forzare un download nelle istanze del ruolo. Per aumentare la disponibilità, i ruoli devono anche contenere un set di dati di riferimento in caso la risorsa di archiviazione non risulti disponibile. In questo modo, i ruoli possono essere avviati con un set di base di dati di riferimento finché la risorsa di archiviazione non torna disponibile per gli aggiornamenti.

Figura 3. Disponibilità elevata delle applicazioni tramite nodi di calcolo autonomi

Un aspetto da considerare per questo modello consiste nella velocità di distribuzione e di avvio dei ruoli. Se si distribuiscono o si scaricano grandi quantità di dati di riferimento all'avvio, la quantità di tempo necessaria per eseguire nuove distribuzioni o istanze di ruolo può risultare maggiore. Potrebbe trattarsi di un compromesso accettabile in virtù dell'autonomia ottenuta grazie all'immediata disponibilità dei dati di riferimento in ogni ruolo rispetto al mantenimento di dipendenze da servizi di archiviazione esterni.

I dati transazionali sono quelli generati dall'applicazione in un contesto aziendale. Rappresentano una combinazione del set di processi aziendali implementato dall'applicazione stessa e dei dati di riferimento a supporto di tali processi. Esempi di dati transazionali includono gli ordini, gli avvisi di spedizione, le fatture e le opportunità CRM. I dati transazionali così generati vengono inseriti in sistemi esterni ai fini di mantenimento dei record o di ulteriore elaborazione.

Tenere presente che i dati di riferimento possono cambiare nei rispettivi sistemi. Per questo motivo, i dati transazionali devono salvare il contesto dei dati di riferimento temporizzato in modo da limitare al minimo le dipendenze esterne ai fini della loro coerenza semantica. Considerare ad esempio la rimozione di un prodotto dal catalogo alcuni mesi dopo l'evasione di un ordine. La procedura migliore consiste nell'incorporare il maggior numero possibile di dati di riferimento nella transazione. In questo modo viene mantenuta la semantica associata alla transazione anche se i dati di riferimento sono stati modificati successivamente all'acquisizione della transazione.

Come indicato in precedenza, le architetture che utilizzano comunicazioni asincrone o loosely-coupled si prestano a livelli più elevati di disponibilità. Ciò vale anche per i dati transazionali, tuttavia l'implementazione è più complessa. Le nozioni transazionali tradizionali si basano in genere sul database per garantire la transazione. Se si introducono livelli intermedi, il codice dell'applicazione deve gestire correttamente i dati ai vari livelli in modo da assicurare coerenza e durabilità sufficienti.

La sequenza seguente descrive un flusso di lavoro che separa l'acquisizione di dati transazionali dalla loro elaborazione:

  1. Nodo di calcolo Web: presentazione dei dati di riferimento.

  2. Archiviazione esterna: salvataggio dei dati transazionali intermedi.

  3. Nodo di calcolo Web: completamento della transazione dell'utente finale.

  4. Nodo di calcolo Web: invio dei dati transazionali completati insieme al contesto dei dati di riferimento a una risorsa di archiviazione durevole temporanea che garantisce una risposta prevedibile.

  5. Nodo di calcolo Web: notifica all'utente finale del completamento della transazione.

  6. Nodo di calcolo in background: estrazione dei dati transazionali, eventuale post-elaborazione e invio alla posizione di archiviazione finale nel sistema corrente.

Nel diagramma seguente è illustrata una possibile implementazione di questa struttura in un servizio cloud di Azure.

Figura 4. Disponibilità elevata delle applicazioni tramite regime di controllo libero ("loosely-coupled")

Le frecce tratteggiate nel diagramma sopra indicano l'elaborazione asincrona invisibile al ruolo Web front-end. Ciò comporta l'archiviazione della transazione nella destinazione finale con riferimento al sistema corrente. A causa della latenza introdotta da questo modello asincrono, i dati transazionali sono immediatamente disponibili per le query, pertanto ogni unità dei dati transazionali deve essere salvata in una cache o nella sessione utente per soddisfare le esigenze immediate dell'interfaccia utente.

Di conseguenza, il ruolo Web è autonomo dal resto dell'infrastruttura. Il relativo profilo di disponibilità è una combinazione del ruolo Web e della coda di Azure, non dell'intera infrastruttura. Oltre alla disponibilità elevata, questo approccio consente la scalabilità orizzontale del ruolo Web indipendentemente dalla risorsa di archiviazione back-end. Questo modello di disponibilità elevata può avere impatto sull'economia delle operazioni, in quanto componenti aggiuntivi quali le code di Azure e i ruoli di lavoro possono influire sui costi di utilizzo mensili.

Si noti che nel diagramma precedente viene illustrata un'implementazione di questo approccio separato ai dati transazionali. Esistono numerose altre implementazioni possibili. Nell'elenco seguente sono indicate alcune varianti alternative.

  • È possibile inserire un ruolo di lavoro tra il ruolo Web e la coda di archiviazione.

  • È possibile utilizzare una coda di Service Bus anziché una coda di archiviazione di Azure.

  • La destinazione finale può essere una risorsa di archiviazione di Azure oppure un altro provider di database.

  • È possibile utilizzare il servizio Azure Caching a livello Web per soddisfare i requisiti immediati di memorizzazione nella cache in seguito alla transazione.

Oltre ai modelli descritti in questa sezione, è importante notare che la scalabilità del servizio cloud influisce direttamente sulla disponibilità. Se il servizio smette di rispondere a causa dell'aumento del carico, per l'utente è come se l'applicazione non fosse disponibile. Attenersi alle procedure consigliate per la scalabilità a seconda delle aspettative presenti e future in termini di carico dell'applicazione. Per conseguire la massima scalabilità è necessario considerare molti aspetti, ad esempio l'uso di uno o più account di archiviazione, la condivisione tra più database e le strategie di memorizzazione nella cache. Per un esame approfondito di questi modelli, vedere Procedure consigliate per la progettazione di servizi su larga scala nei servizi cloud di Azure.

Mentre la disponibilità elevata è incentrata sulla gestione degli errori temporanei, il ripristino di emergenza è incentrato sulla perdita irreversibile delle funzionalità dell'applicazione. Considerare ad esempio uno scenario in cui uno o più data center smettono di funzionare. In questo caso è necessario disporre di un piano per eseguire l'applicazione o accedere ai dati all'esterno del data center. L'esecuzione di questo piano coinvolge persone, processi e applicazioni di supporto in grado di garantire il funzionamento del sistema. Il livello di funzionalità del servizio durante una condizione di emergenza è determinato dai proprietari di processi aziendali e tecnologie, che definiscono le modalità operative di emergenza. Questo livello di funzionalità può variare notevolmente e prevedere la completa indisponibilità, una disponibilità parziale (con funzionalità ridotte o ritardi nell'elaborazione) o la disponibilità completa.

Come per la disponibilità, Azure offre numerose funzionalità per la continuità aziendale progettate per supportare il ripristino di emergenza, descritte nell'articolo Informazioni tecniche sulla continuità aziendale di Azure. Esiste inoltre un rapporto tra alcune delle funzionalità di disponibilità di Azure e il ripristino di emergenza. Ad esempio, la gestione dei ruoli tra domini di errore aumenta la disponibilità di un'applicazione. Senza questo tipo di gestione, un guasto hardware non gestito diventerebbe uno scenario di "emergenza". Pertanto, l'applicazione corretta di molte delle funzionalità e delle strategie per la disponibilità deve essere considerata come una parte importante delle iniziative per rendere le applicazioni a prova di emergenza. Questa sezione va tuttavia al di là delle problematiche generali sulla disponibilità per illustrare eventi di emergenza più gravi (e più rari).

I data center di Azure sono dislocati in diverse aree del mondo. Ciò supporta diversi scenari di ripristino di emergenza, ad esempio la replica geografica fornita dal sistema del servizio di archiviazione di Azure in data center secondari. Significa anche che è possibile distribuire in modo semplice ed economico un servizio cloud in diverse località del mondo. È utile confrontare questo vantaggio con i costi e le difficoltà correlate al mantenimento di data center propri in più paesi. La distribuzione di dati e servizi in più data center consente di proteggere le applicazioni dal rischio di gravi interruzioni in un singolo data center.

Quando si verifica un problema specifico di un data center, è necessario reindirizzare il traffico a servizi o distribuzioni in un altro data center. Questo routing può essere eseguito manualmente, ma l'uso di un processo automatizzato risulta più efficiente. Gestione traffico di Azure è progettato per questa attività. Consente di gestire in modo automatico il failover del traffico utente in un altro data center in caso di problemi nel data center principale. Poiché la gestione del traffico rappresenta un aspetto importante della strategia complessiva, è fondamentale comprendere le caratteristiche di base di Gestione traffico di Azure.

Nella figura seguente, gli utenti si connettono a un URL specificato per Gestione traffico di Azure (http://myATMURL.trafficmanager.net) che astrae gli URL del sito effettivi (http://app1URL.cloudapp.net e http://app2URL.cloudapp.net). Gli utenti verranno inviati al sito effettivo corretto in base ai criteri di instradamento configurati. Le opzioni dei criteri sono round-robin, prestazioni o failover. Ai fini di questo white paper, ci occuperemo solo dell'opzione di failover.

Figura 5. Routing mediante Gestione traffico di Azure

Quando si configura Gestione traffico di Azure viene fornito un nuovo prefisso DNS di Gestione traffico. Si tratta del prefisso di URL da fornire agli utenti per accedere al servizio. Il bilanciamento del carico viene ora astratto da Gestione traffico di Azure a un livello superiore e non più al livello del data center. Viene eseguito il mapping di DNS di Gestione traffico a un CNAME per tutte le distribuzioni gestite.

In Gestione traffico di Azure si specifica la priorità delle distribuzioni verso cui instradare gli utenti in caso di problemi. Gestione traffico di Azure monitora gli endpoint delle distribuzioni e rileva se quella primaria presenta problemi. In caso di errore, Gestione traffico di Azure analizza l'elenco con priorità delle distribuzioni e instrada gli utenti a quella successiva.

Sebbene Gestione traffico di Azure decida dove eseguire un failover, l'utente può decidere se il dominio di failover è inattivo o attivo quando NON si trova in modalità di failover. Tale funzionalità non è correlata a Gestione traffico di Azure. Gestione traffico di Azure rileva un problema nel sito principale e passa al sito di failover. L'operazione avviene indipendentemente dal fatto che tale sito sia attualmente attivo per gli utenti o meno. Altre informazioni sui domini di failover inattivi o attivi sono disponibili più avanti in questo documento.

Per altre informazioni sul funzionamento di Gestione traffico di Azure, visitare i collegamenti seguenti.

Nelle sezioni seguenti sono illustrati diversi tipi di scenari di emergenza. Il guasto di un data center non rappresenta l'unica causa possibile di errori a livello di applicazione. Errori di progettazione o di amministrazione possono determinare interruzioni dei servizi. È importante tenere conto delle possibili cause di un errore sia durante le fasi di progettazione sia durante quelle di test del piano di ripristino. Piani validi sfruttano le funzionalità di Azure e le corredano di strategie specifiche per l'applicazione. La risposta scelta è dettata dall'importanza dell'applicazione e dagli obiettivi RPO e RTO.

Come indicato in precedenza, il controller di infrastruttura di Azure gestisce automaticamente gli errori derivanti dall'hardware o dal sistema operativo sottostante nella macchina virtuale host. Azure crea una nuova istanza del ruolo in un server funzionante e lo aggiunge alla rotazione del servizio di bilanciamento del carico. Se il numero di istanze del ruolo è maggiore di uno, Azure passa l'elaborazione alle altre istanze del ruolo in esecuzione mentre sostituisce il nodo in cui è presente il problema.

Esistono tuttavia errori gravi delle applicazioni che si verificano indipendentemente dai problemi di hardware o sistema operativo. L'applicazione potrebbe smettere di funzionare a causa di eccezioni irreversibili causate da logica errata o da problemi di integrità dei dati. È necessario integrare telemetria sufficiente nel codice in modo che un sistema di monitoraggio possa rilevare le condizioni di errore e inviare notifiche a un amministratore dell'applicazione. Grazie alla piena conoscenza dei processi di ripristino di emergenza, l'amministratore può decidere di richiamare un processo di failover oppure di accettare semplicemente un'interruzione della disponibilità per risolvere gli errori critici.

Azure archivia automaticamente i dati del database SQL di Azure e del servizio di archiviazione di Azure tre volte, in modo ridondante in diversi domini di errore nello stesso data center. Se si utilizza la replica geografica, questa viene archiviata per altre tre volte in un altro data center. Se tuttavia gli utenti o l'applicazione danneggiano i dati nella copia primaria, gli errori vengono rapidamente replicati in altre copie. Ciò comporta la creazione di tre copie di dati danneggiati.

Per gestire il potenziale danneggiamento dei dati, è necessario provvedere a effettuare propri backup che consentano di assicurare la coerenza transazionale. È possibile archiviare i backup in Azure oppure in locale in base ai requisiti aziendali o alle normative di governance. Per altre informazioni, vedere la sezione Strategie dei dati per il ripristino di emergenza.

Se parti della rete di Azure sono inattive, potrebbe non essere possibile accedere all'applicazione o ai dati. Se una o più istanze del ruolo non risultano disponibili a causa di problemi di rete. Azure sfrutta le istanze disponibili rimanenti dell'applicazione. Se l'applicazione non è in grado di accedere ai dati a causa di un'interruzione della rete di Azure, è potenzialmente possibile ricorrere all'esecuzione locale con funzionalità ridotte utilizzando dati memorizzati nella cache. È necessario progettare la strategia di ripristino di emergenza per l'esecuzione in modalità con funzionalità ridotte dell'applicazione. Per alcune applicazioni questa soluzione potrebbe non essere pratica. Un'altra opzione consiste nell'archiviare i dati in una posizione alternativa finché non viene ripristinata la connettività. Se la modalità con funzionalità ridotte non è praticabile, le opzioni rimanenti sono l'interruzione dell'applicazione o il failover a un data center alternativo. La progettazione di un'applicazione per l'esecuzione con funzionalità ridotte dipende da considerazioni sia di natura aziendale sia di natura tecnica. Questi aspetti sono ulteriormente illustrati nella sezione Esecuzione delle applicazioni con funzionalità ridotte.

Azure offre numerosi servizi che possono incorrere periodicamente in tempi di inattività. Un esempio è rappresentato dal servizio Shared Caching di Azure. Questo servizio multitenant offre funzionalità di memorizzazione nella cache per le applicazioni. È importante valutare l'impatto sull'applicazione in caso di indisponibilità di un servizio dipendente. Per molti versi questo scenario è analogo a quello di interruzione della rete, tuttavia se si tiene conto di ogni servizio singolarmente è possibile apportare miglioramenti al piano generale.

Ad esempio, con la memorizzazione nella cache esiste un'alternativa relativamente nuova al modello di Shared Caching multitenant. Azure Caching nei ruoli conferisce all'applicazione funzionalità di memorizzazione nella cache all'interno della distribuzione del servizio cloud (si tratta anche della modalità d'uso d'ora in poi consigliata per Caching). Sebbene vi sia la limitazione di potervi accedere solo da una singola distribuzione, esistono potenziali vantaggi per il ripristino di emergenza. In primo luogo, il servizio viene ora eseguito sui ruoli locali rispetto alla distribuzione. Pertanto è consigliabile prevedere il monitoraggio e la gestione dello stato della cache nell'ambito dei processi di gestione generali del servizio cloud. Questo tipo di memorizzazione nella cache espone anche nuove funzionalità. Una di queste è la disponibilità elevata per i dati memorizzati in cache. Ciò agevola la protezione dei dati in cache nel caso in cui un singolo nodo smetta di funzionare, mantenendo copie duplicate in altri nodi. Si noti che la disponibilità elevata riduce la velocità effettiva e aumenta la latenza a causa dell'aggiornamento della copia secondaria durante le operazioni di scrittura. Raddoppia inoltre la quantità di memoria utilizzata per ogni elemento. Pertanto, è consigliabile tenere conto di questi aspetti nella pianificazione. Questo esempio specifico dimostra che ogni servizio dipendente può disporre di funzionalità che migliorano la disponibilità e la resistenza generali agli errori irreversibili.

È consigliabile esaminare le implicazioni di un'interruzione totale su ogni servizio dipendente. Nell'esempio relativo a Caching, potrebbe essere possibile accedere ai dati direttamente da un database finché le funzionalità di Caching non vengono ripristinate. Si tratterebbe di una condizione con funzionalità ridotte in termini di prestazioni, tuttavia sarebbero disponibili tutte le funzionalità correlate ai dati.

I problemi indicati in precedenza sono principalmente errori gestibili nel medesimo data center di Azure. È tuttavia necessario prepararsi anche all'eventualità che si verifichi un problema tale da rendere indisponibile l'intero data center. Quando un data center smette di funzionare, le copie ridondanti locali dei dati non sono disponibili. Se è stata abilitata la replica geografica, esistono altre tre copie dei BLOB e delle tabelle in un data center in una diversa area. Quando Microsoft dichiara la perdita di un data center, Azure esegue nuovamente il mapping di tutte le voci DNS al data center con replica geografica. Si noti che i clienti non hanno controllo su questo processo, il quale si verifica solo in caso di guasti a livello dell'intero data center. Per questo motivo, è necessario affidarsi anche ad altre strategie di backup specifiche dell'applicazione per conseguire livelli massimo di disponibilità. Per altre informazioni, vedere la sezione Strategie dei dati per il ripristino di emergenza.

Nella pianificazione relativa alle condizioni di emergenza, è necessario considerare tutta la gamma dei possibili eventi. Una delle problematiche più gravi è rappresentata dall'eventuale interessamento di tutti i data center di Azure contemporaneamente. Come per altri tipi di problemi, è possibile in questo caso decidere di accettare il rischio di un temporaneo periodo di inattività. Errori diffusi tra più data center dovrebbero essere più rari rispetto a errori isolati di servizi dipendenti o singoli data center. Tuttavia, per alcune applicazioni cruciali si potrebbe decidere di disporre di un piano di backup anche per questo tipo di scenario. Il piano per questo evento può includere il failover su servizi in Cloud alternativi o Soluzioni cloud e locali ibride.

Un'applicazione ben progettata utilizza in genere una raccolta di moduli che comunicano tra loro tramite l'implementazione di modelli di scambio di informazioni a regime di controllo libero ("loosely-coupled"). In particolare, un'applicazione adatta a scenari di ripristino di emergenza richiede la separazione dei compiti a livello di modulo in modo che l'interruzione di un servizio dipendente non causi l'interruzione dell'intera applicazione. Ad esempio, nel caso di un'applicazione di e-commerce sul Web di una società Y, tale applicazione potrebbe essere costituita dai moduli seguenti:

  • Catalogo dei prodotti: consente agli utenti di sfogliare i prodotti

  • Carrello degli acquisti: supporta l'aggiunta e la rimozione di prodotti nel carrello

  • Stato dell'ordine: mostra lo stato degli ordini di acquisto degli utenti

  • Invio dell'ordine: consente di finalizzare la sessione di acquisto tramite l'invio dell'ordine con il pagamento

  • Elaborazione dell'ordine: convalida l'integrità dei dati dell'ordine e verifica la disponibilità della quantità richiesta

Quando una dipendenza di un modulo dell'applicazione non è disponibile, in che modo deve funzionare il modulo in questione finché non si provvede al ripristino? In un sistema ben strutturato, si implementano limiti di isolamento mediante la separazione delle attività sia in fase di progettazione che in fase di esecuzione. Ogni errore può essere classificato come reversibile o non reversibile. Gli errori irreversibili interrompono il funzionamento del modulo, mentre quelli reversibili possono essere attenuati tramite alternative. Come illustrato nella sezione sulla disponibilità elevata, alcuni problemi possono essere nascosti agli utenti gestendo gli errori ed eseguendo azioni alternative. In caso di problemi più gravi, l'applicazione potrebbe risultare del tutto non disponibile. Una terza opzione tuttavia consiste nel continuare a servire gli utenti con funzionalità ridotte.

Se ad esempio il database che ospita gli ordini non è disponibile, il modulo di elaborazione degli ordini non è in grado di elaborare le transazioni di vendita. A seconda dell'architettura, potrebbe essere difficile se non impossibile continuare a utilizzare i moduli per l'invio e l'elaborazione degli ordini. Se l'applicazione non è progettata per gestire questo scenario, essa potrebbe essere completamente offline.

Tuttavia, nello stesso scenario, è possibile che i dati dei prodotti siano archiviati in un altra posizione. In questo caso, è comunque possibile continuare a utilizzare il modulo del catalogo per esaminare i prodotti. Nella modalità con funzionalità ridotte, l'applicazione continua a offrire agli utenti le funzioni disponibili, ad esempio l'esplorazione del catalogo prodotti. Altri componenti dell'applicazione, come gli ordini e le query sull'inventario, non sono invece disponibili.

Un'altra variante della modalità con funzionalità ridotte è incentrata sulle prestazioni anziché le capacità. Si consideri ad esempio uno scenario in cui il catalogo dei prodotti viene memorizzato in cache con il servizio Azure Caching. Se tale servizio risulta non disponibile, l'applicazione potrebbe accedere direttamente alla risorsa di archiviazione server per recuperare i dati del catalogo. Questo tipo di accesso potrebbe tuttavia risultare più lento rispetto alla versione con memorizzazione nella cache. Per questo motivo, le prestazioni dell'applicazione risultano ridotte finché il servizio Caching non viene completamente ripristinato.

La decisione sulla misura in cui un'applicazione continuerà a funzionare in modalità con funzionalità ridotte implica considerazioni di natura sia aziendale che tecnica. Deve essere inoltre stabilito come informare gli utenti dei problemi temporanei. In questo esempio, l'applicazione potrebbe consentire la visualizzazione dei prodotti e perfino la loro aggiunta al carrello degli acquisti. Tuttavia, quando l'utente tenta di eseguire un acquisto, viene visualizzata una notifica indicante che il modulo di vendita è temporaneamente non disponibile. Non si tratta di una situazione ideale per il cliente, ma impedisce un'interruzione a livello dell'intera applicazione.

La corretta gestione dei dati rappresenta l'aspetto più complesso di qualsiasi piano per il ripristino di emergenza. Il ripristino dei dati rappresenta anche la parte del processo di ripristino che richiede in genere più tempo. Le diverse opzioni relative alle modalità di riduzione delle prestazioni implicano problematiche complesse per quanto concerne il ripristino e la coerenza dei dati in seguito a un errore. Uno dei fattori implicati consiste nella necessità di ripristinare o mantenere una copia dei dati dell'applicazione. Questi dati verranno utilizzati per finalità referenziali o transazionali in un sito secondario. In una struttura locale ciò richiede un processo di pianificazione lungo e costoso per implementare una strategia di ripristino di emergenza con più data center. Per praticità, la maggior parte dei provider di cloud, incluso Azure, consente l'immediata distribuzione delle applicazioni in più data center. Questi data center sono dislocati in aree geografiche diverse in modo che l'eventualità che si verifichi un'interruzione di più data center sia estremamente rara. La strategia di gestione dei dati tra più data center è uno dei fattori determinanti per il successo di qualsiasi piano di ripristino di emergenza.

Nelle sezioni seguenti vengono illustrare le tecniche di ripristino di emergenza correlate ai backup dei dati, ai dati di riferimento e ai dati transazionali.

I backup regolari dei dati delle applicazioni possono supportare alcuni scenari di ripristino di emergenza. Le tecniche variano a seconda delle diverse risorse di archiviazione.

Per il database SQL di Azure, è possibile utilizzare il comando DATABASE COPY per creare una copia del database. È necessario utilizzare questo comando per ottenere un backup con coerenza transazionale. È anche possibile sfruttare il servizio di importazione/esportazione del database SQL di Azure. Questo servizio supporta l'esportazione dei database in file BACPAC archiviati nella risorsa di archiviazione BLOB di Azure. La ridondanza predefinita del servizio di archiviazione di Azure crea due repliche del file di backup nello stesso data center. Tuttavia, la frequenza di esecuzione del processo di backup determina l'obiettivo RPO, ovvero la quantità di dati che potrebbero essere persi negli scenari di emergenza. Se ad esempio si esegue un backup ogni ora esatta e l'emergenza si verifica due minuti prima dello scadere dell'ora, vengono persi 58 minuti di dati creati dopo l'ultimo backup. Inoltre, per tutelarsi dalle interruzioni di un data center, è consigliabile copiare i file BACPAC in un data center alternativo. È quindi possibile ripristinare questi backup nel data center alternativo. Per altri dettagli, vedere Continuità aziendale nel database SQL di Azure.

Per Archiviazione di Azure è possibile sviluppare un processo di backup personalizzato oppure utilizzare uno strumento di backup di terze parti. Si noti che esistono ulteriori complessità nella maggior parte delle applicazioni laddove le risorse di archiviazione fanno riferimento le une alle altre. Si consideri ad esempio un database SQL con una colonna di collegamento a un BLOB del servizio di archiviazione di Azure. Se i backup non vengono eseguiti contemporaneamente, è possibile che il database contenga il puntatore a un BLOB di cui non è stato eseguito il backup prima dell'errore. Nell'applicazione o nel piano di ripristino di emergenza devono essere implementati processi per la gestione di questa incoerenza successivamente al ripristino.

Come indicato in precedenza, i dati di riferimento sono dati di sola lettura che supportano le funzionalità di un'applicazione. In genere non sono soggetti a modifiche frequenti. Sebbene il backup e il ripristino rappresentino un metodo per gestire le interruzioni dei data center, l'obiettivo RTO è relativamente lungo. Quando l'applicazione viene distribuita in un data center secondario, è possibile ricorrere ad alcune strategie che migliorano l'obiettivo RTO per i dati di riferimento.

Poiché i dati di riferimento vengono raramente modificati, è possibile migliorare l'obiettivo RTO mantenendo una copia permanente di tali dati nel data center secondario. Ciò consente di eliminare i tempi necessari per ripristinare i backup in caso di emergenza. Per soddisfare i requisiti di ripristino di emergenza con più data center, è necessario distribuire l'applicazione e i dati di riferimento insieme in più data center. Come indicato in Modello di dati di riferimento (disponibilità elevata), i dati di riferimento possono essere distribuiti al ruolo stesso, a una risorsa di archiviazione esterna o a una combinazione dei due. Il modello di distribuzione dei dati di riferimento tra nodi di calcolo soddisfa i requisiti di ripristino di emergenza in modo implicito. La distribuzione dei dati di riferimento al database SQL richiede la distribuzione di una copia dei dati in ogni data center. La stessa strategia è applicabile al servizio di archiviazione di Azure. È necessario distribuire una copia di tutti i dati di riferimento archiviati nel servizio di archiviazione di Azure al data center principale e a quello secondario.

Figura 6. Pubblicazione dei dati di riferimento nel data center principale e in quello secondario

Come indicato in precedenza, è necessario implementare proprie routine di backup specifiche dell'applicazione per tutti i dati, inclusi quelli di riferimento. Le copie con replica geografica tra data center vengono utilizzate solo in caso di interruzione a livello di un intero data center. Per evitare tempi di inattività prolungati, distribuire le parti più importanti dei dati dell'applicazione al data center secondario. Per un esempio di questa topologia, vedere il modello Attivo/passivo.

L'implementazione di una strategia che prevede la disponibilità di funzionalità complete in caso di emergenza richiede una replica asincrona dei dati transazionali nel data center secondario. Le finestre temporali possibili in cui può essere eseguita la replica determinano le caratteristiche dell'obiettivo RPO dell'applicazione. I dati persi durante la finestra di replica potrebbero essere comunque ripristinabili dal data center principale e successivamente uniti a quelli nel secondario.

Le architetture di esempio seguenti offrono alcune idee sui diversi modi possibili di gestire i dati transazionali in uno scenario di failover. È importante notare che questi esempi non sono esaustivi. Ad esempio, le posizioni di archiviazione intermedie come le code possono essere sostituite dal database SQL di Azure. Le code stesse possono essere del servizio di archiviazione o di Service Bus di Azure (vedere Code di Azure e Azure Service Bus: confronto e contrapposizioni). Anche le destinazioni di archiviazione server possono variare, ad esempio tabelle di Azure invece del database SQL. Inoltre, potrebbero essere presenti ruoli di lavoro inseriti come intermediari in vari passaggi. L'importante non è emulare queste architetture in modo preciso, bensì valutare varie alternative per il ripristino di dati transazionali e moduli correlati.

Si consideri un'applicazione che utilizza le code di archiviazione di Azure per i dati transazionali. Ciò consente ai ruoli di lavoro di elaborare i dati transazionali nel database server in un'architettura separata. Come descritto, ciò richiede che per le transazioni si utilizzi una qualche forma di memorizzazione nella cache temporanea se i ruoli front-end richiedono la possibilità di eseguire immediatamente query sui dati. A seconda del livello di tolleranza alle perdita dei dati, si può scegliere di replicare le code, il database o tutte le risorse di archiviazione. Limitandosi alla replica del database, in caso di interruzione del data center primario, i dati nelle code possono essere comunque ripristinati quando il data center principale torna disponibile. Nella figura seguente è illustrata un'architettura in cui il database server è sincronizzato tra più data center.

Figura 7. Replica dei dati transazionali in preparazione del ripristino di emergenza.

Il problema maggiore nell'implementazione dell'architettura precedente consiste nella strategia di replica tra i data center. Azure offre un servizio di sincronizzazione dati SQL per questo tipo di replica. Questo servizio, tuttavia, è ancora in anteprima e non è consigliato per ambienti di produzione. Per altre informazioni, vedere Continuità aziendale nel database SQL di Azure. Per le applicazioni di produzione, è necessario investire in una soluzione di terze parti o creare una logica di replica personalizzata nel codice. A seconda dell'architettura, la replica può essere bidirezionale, la quale è anche più complessa. In una possibile implementazione ci si potrebbe avvalere della coda intermedia illustrata nell'esempio precedente. Il ruolo di lavoro che elabora i dati nella destinazione di archiviazione finale potrebbe apportare la modifica sia nel data center principale che in quello secondario. Non si tratta di attività semplici, ma istruzioni complete relative al codice di replica esulano dall'ambito di questo documento. L'aspetto importante è che occorre dedicare molto tempo e attività di testing alla modalità di replica dei dati nel data center secondario. È inoltre consigliabile eseguire attività di elaborazione e testing aggiuntive per accertarsi che i processi di failover e ripristino gestiscano correttamente eventuali incoerenze dei dati o transazioni duplicate.

noteNota
La maggior parte di questo documento è incentrata sul modello PaaS. Esistono comunque altre opzioni di replica e disponibilità per applicazioni ibride che utilizzano macchine virtuali di Azure. Queste applicazioni ibride utilizzano il modello IaaS per ospitare SQL Server su macchine virtuali in Azure. Ciò consente di adottare gli approcci tradizionali di SQL Server alla disponibilità, ad esempio i gruppi di disponibilità AlwaysOn o il log shipping. Alcune tecniche, come AlwaysOn, funzionano solo tra istanze di SQL Server locali e macchine virtuali di Azure. Per altre informazioni, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

Si consideri una seconda architettura che operi in modalità con funzionalità ridotte. L'applicazione nel data center secondario disattiva tutte le funzionalità, ad esempio report, BI o svuotamento delle code. Accetta solo i tipi di flussi di lavoro transazionali più importanti come definito dai requisiti aziendali. Il sistema acquisisce le transazioni e le scrive nelle code e può differire l'elaborazione dei dati durante la fase iniziale dell'interruzione. Se il sistema nel data center principale si riattiva entro il tempo previsto, le code possono essere svuotate dai ruoli di lavoro del data center principale, eliminando così la necessità di unire i database. Se l'interruzione del data center principale si prolunga oltre un tempo accettabile, l'applicazione può iniziare a elaborare le code. In questo scenario il database nel data center secondario contiene dati transazionali incrementali che devono essere uniti alla riattivazione di quello principale. Nella figura seguente viene illustrata questa strategia per l'archiviazione temporanea di dati transazionali fino al ripristino del data center principale.

Figura 8. Modalità dell'applicazione con funzionalità ridotte solo per l'acquisizione delle transazioni

Per altre informazioni sulle tecniche di gestione dei dati per applicazioni Azure resilienti, vedere Operatore alternativo: informazioni aggiuntive per architetture cloud resilienti.

Preparare le applicazioni cruciali all'eventualità che l'intero sistema risulti non disponibile. A questo scopo, integrare una strategia di distribuzione a più data center nella pianificazione operativa. Le distribuzioni a più data center devono includere processi IT avanzati per pubblicare l'applicazione e i dati di riferimento nel data center secondario in seguito a un'emergenza. Se l'applicazione richiede il failover immediato, il processo di distribuzione deve prevedere una configurazione attivo/passivo o attivo/attivo. Questo tipo di distribuzione include istanze esistenti dell'applicazione in esecuzione nel data center alternativo. Come illustrato in precedenza, uno strumento di routing come Gestione traffico di Azure offre servizi di bilanciamento del carico a livello di DNS. È in grado di rilevare le interruzioni e indirizzare gli utenti a data center diversi, a seconda delle necessità.

Ai fini di un corretto ripristino di emergenza in Azure, è importante definire l'architettura di tale ripristino all'interno della soluzione fin dall'inizio. Il cloud mette a disposizione altre opzioni per il ripristino da condizioni di errore durante un'emergenza che non sono disponibili in un provider di hosting tradizionale. In particolare, è possibile allocare in modo rapido e dinamico le risorse in un altro data center. Si evitano così costi consistenti riferiti alle risorse inattive in attesa che si verifichi un errore.

Nelle sezioni seguenti vengono illustrare diverse topologie di distribuzioni per il ripristino di emergenza. Una maggiore disponibilità comporta generalmente un compromesso in termini di aumento dei costi o della complessità.

Le distribuzioni in una singola area non sono in effetti topologie di ripristino di emergenza, ma sono illustrate come termine di confronto rispetto ad altre architetture. Le distribuzioni di questo tipo sono comuni per le applicazioni in Azure. Non si tratta comunque di una valida alternativa a un piano di ripristino di emergenza. Nel diagramma seguente è illustrata un'applicazione eseguita in un singolo data center di Azure. Come illustrato in precedenza, il controller di infrastruttura di Azure e l'uso di domini di errore e di aggiornamento aumentano la disponibilità dell'applicazione nel data center.

Figura 9. Distribuzione in una singola area

In questo caso è evidente che il database rappresenti un singolo punto di errore. Sebbene Azure replichi i dati tra diversi domini di errore in repliche interne, il tutto avviene nello stesso data center. Non risulta quindi possibile sostenere gravi circostanze di emergenza. Se il data center smette di funzionare, tutti di domini di errore risultano non disponibili, incluse tutte le istanze dei servizi e le risorse di archiviazione.

Per tutte le applicazioni, tranne le meno importanti, è necessario definire un piano per la distribuzione tra più data center in aree geografiche diverse. È inoltre consigliabile tenere conto degli obiettivi RTO e dei vincoli di costi quando si valuta la topologia di distribuzione da utilizzare.

Esaminiamo ora specifici modelli che supportano il failover tra data center diversi. Questi esempi utilizzano tutti due data center per descrivere il processo.

In questo modello applicazioni e database sono in esecuzione solo nel data center principale. Il data center secondario non è configurato per il failover automatico. Pertanto, quando si verifica un'emergenza, è necessario attivare tutti i componenti del servizio nel nuovo data center. Ciò include il caricamento di un servizio cloud in Azure, la distribuzione dei servizi cloud, il ripristino dei dati e la modifica del DNS per il reindirizzamento del traffico.

Sebbene si tratti della più economica tra le opzioni multiarea, è la soluzione con le caratteristiche peggiori in termini di RTO. In questo modello i backup del database e del pacchetto del servizio vengono archiviati in locale o nella risorsa di archiviazione BLOB del data center secondario. Tuttavia, è necessario distribuire un nuovo servizio e ripristinare i dati prima di tornare operativi. Anche se si automatizza completamente il trasferimento dei dati dall'archivio di backup, l'attivazione del nuovo ambiente di database può comunque richiedere una notevole quantità di tempo. Lo spostamento dei dati dal disco di backup al database vuoto nel data center secondario costituisce la parte più onerosa del ripristino. Si tratta comunque di un'operazione necessaria per portare il nuovo database in uno stato operativo dal momento che non è replicato.

L'approccio migliore consiste nell'archiviare i pacchetti dei servizi nella risorsa di archiviazione BLOB di Azure nel data center secondario. Ciò consente di eliminare la necessità di caricare il pacchetto in Azure, come invece avviene quando si effettua distribuzione da un computer di sviluppo locale. I pacchetti dei servizi possono essere distribuiti rapidamente in un nuovo servizio cloud dalla risorsa di archiviazione BLOB mediante script di PowerShell.

Questa opzione è pratica solo per applicazioni non critiche che tollerano RTO elevati. Ad esempio, questa soluzione potrebbe funzionare per un'applicazione che può rimanere non disponibile per diverse ore ma che deve tornare operativa entro 24 ore.

Figura 10. Ridistribuzione in un data center secondario di Azure

Il modello attivo/passivo rappresenta la scelta preferita da molte società. Offre miglioramenti in termini di RTO con un aumento dei costi relativamente contenuto rispetto al modello di ridistribuzione. Anche questo scenario prevede un data center principale e uno secondario di Azure. Tutti il traffico è indirizzato alla distribuzione attiva nel data center principale. Il data center secondario è preparato in modo ottimale per il ripristino di emergenza in quanto il database è in esecuzione in entrambi i data center. Inoltre, tra di essi è presente un meccanismo di sincronizzazione. Questo approccio in stand-by può prevedere due varianti: una con solo database oppure una distribuzione completa nel data center secondario.

Nella prima variante del modello attivo/passivo, l'applicazione del servizio cloud è distribuita solo nel data center principale. Tuttavia, a differenza del modello di ridistribuzione, i contenuti del database sono sincronizzati in entrambi i data center (vedere la sezione Modello di dati transazionali (ripristino di emergenza)). In caso di emergenza, i requisiti di attivazione sono minori. Si avvia l'applicazione nel data center secondario, si cambiano le stringhe di connessione al nuovo database e si modificano le voci DNS per reindirizzare il traffico.

Come nel modello di ridistribuzione, i pacchetti del servizio devono essere già archiviati nella risorsa di archiviazione BLOB di Azure nel data center secondario in modo che la distribuzione risulti più rapida. A differenza del modello di ridistribuzione, non si incorre nella maggior parte degli oneri aggiuntivi necessari per le operazioni di ripristino del database. Il database è pronto e in esecuzione. Ciò consente di risparmiare una considerevole quantità di tempo, rendendo questo un modello conveniente e pertanto particolarmente diffuso di ripristino di emergenza.

Figura 11. Attivo/passivo (solo database)

Nella seconda variante del modello attivo/passivo, in entrambi i data center principale e secondario è presente una distribuzione completa. Questa distribuzione completa include i servizi cloud e un database sincronizzato. Solo il data center principale, tuttavia, gestisce attivamente le richieste di rete degli utenti. Quello secondario si attiva solo quando il data center principale non è disponibile. In questo caso, tutte le richieste di rete vengono reindirizzate all'area secondaria. Gestione traffico di Azure è in grado di gestire questo tipo di failover in modo automatico.

Il failover avviene più velocemente rispetto alla variante con il solo database, in quanto i servizi sono già distribuiti. Questo modello assicura un RTO molto basso: il data center di failover secondario deve essere immediatamente pronto in caso di problemi con quello principale.

Oltre che una reazione più rapida, questo scenario implica l'ulteriore vantaggio della pre-allocazione e distribuzione dei servizi di backup. Non è necessario preoccuparsi che il data center non disponga di spazio sufficiente per allocare nuove istanze in caso di emergenza. Si tratta di un aspetto importante se la capacità del data center secondario di Azure è prossima all'esaurimento. Non c'è garanzia (contratto di servizio) che si sia immediatamente in grado di distribuire numerosi nuovi servizi cloud in uno o più data center.

Per ottenere un tempo di risposta molto rapido con questo modello, è necessario disporre di un numero di istanze di ruolo simile nel data center principale e in quello secondario. Nonostante i vantaggi, i costi associati alle istanze di calcolo inutilizzate sono elevati e spesso non si tratta delle scelta finanziaria più prudente. Per questo motivo, spesso viene utilizzata una versione leggermente ridotta dei servizi cloud sul data center secondario. È quindi possibile provvedere rapidamente al failover e alla scalabilità orizzontale della distribuzione secondaria a seconda delle necessità. È consigliabile automatizzare il processo di failover in modo che, in caso di problemi del data center principale, vengano attivate istanze aggiuntive a seconda del carico. Ciò può implicare un qualche meccanismo di ridimensionamento automatico, ad esempio l'anteprima della scalabilità automatica o il blocco di applicazioni per la scalabilità automatica. Nel diagramma seguente è illustrato un modello in cui sia il data center principale sia quello secondario dispongono di una distribuzione completa del servizio cloud secondo il modello attivo/passivo.

Figura 12. Attivo/passivo (replica completa)

A questo punto, è probabilmente facile evincere la tendenza di questi modelli, ovvero che la riduzione dell'obiettivo RTO corrisponde a un aumento di costi e complessità. La soluzione di tipo attivo/attivo contraddice questa tendenza per quanto riguarda i costi. In un modello attivo/attivo, i servizi cloud e il database sono distribuiti completamente in entrambi i data center. A differenza del modello attivo/passivo, entrambi i data center ricevono il traffico degli utenti. Questa opzione implica il tempo di ripristino minore. I servizi sono di dimensioni già adeguate a gestire una parte del carico in ognuno dei data center. Il DNS è già in grado di utilizzare il data center secondari. La complessità aggiuntiva consiste nel determinare la modalità di indirizzamento degli utenti al data center appropriato. È possibile adottare una pianificazione di tipo round-robin. È più probabile che determinati utenti utilizzino un data center specifico in cui risiede la copia primaria dei propri dati.

In caso di failover, è sufficiente disabilitare le voci DNS relative al data center principale, in modo da indirizzare tutto il traffico a quello secondario. Anche questo modello presenta alcune varianti. Ad esempio, nel diagramma seguente è illustrato un modello in cui il data center principale dispone della copia master del database. I servizi cloud in entrambi i data center scrivono sul database primario. La distribuzione secondaria può leggere dal database primario o da quello replicato. La replica in questo esempio è unidirezionale.

Figura 13. Attivo/attivo

Un lato negativo dell'architettura di tipo attivo/attivo è evidente nel diagramma precedente. Il secondo data center deve accedere al database nel primo, poiché è in quest'ultimo che si trova la copia master. Le prestazioni si riducono sensibilmente quando si accede a dati all'esterno di un data center. Nelle chiamate di database tra data center, è necessario tenere conto di un qualche tipo di strategia di invio in batch per migliorare le prestazioni. Per altre informazioni, vedere la pagina relativa alle tecniche di invio in batch per applicazioni di database SQL in Azure. Un'architettura alternativa può prevedere che ogni data center acceda direttamente al proprio database. In questo modello, è necessario un qualche tipo di replica bidirezionale per sincronizzare i database in ciascun data center.

Nel modello attivo/attivo può non essere necessario che nel data center principale sia presente lo stesso numero di istanze del modello attivo/passivo. Se si dispone di dieci istanze del data center principale nell'architettura di tipo attivo/passivo, potrebbero esserne sufficienti solo cinque in ogni data center dell'architettura di tipo attivo/attivo. Le due aree condividono ora il carico. Ciò può determinare riduzioni dei costi rispetto al modello attivo/passivo se si tiene in warm standby il data center passivo con dieci istanze in attesa di failover.

Tenere presente che finché il data center principale non viene ripristinato, quello secondario potrebbe ricevere un improvviso carico di nuovi utenti. Se vi sono 10.000 utenti su ogni server quando si verifica il guasto nel data center principale, quello secondario potrebbe trovarsi improvvisamente a doverne gestire 20.000. Le regole di monitoraggio nel data center secondario devono rilevare questo aumento e raddoppiare le istanze nel data center secondario. Per altre informazioni, vedere la sezione Rilevamento degli errori.

Un'altra strategia per il ripristino di emergenza consiste nella progettazione di un'applicazione ibrida eseguita sia in locale che nel cloud. A seconda dell'applicazione, il data center principale può trovarsi in una o nell'altra posizione. Si considerino le architetture precedenti e si immagini il data center principale o quello secondario come una risorsa locale.

Le architetture ibride presentano diverse problematiche. In primo luogo, la maggior parte di questo articolo è incentrata sui modelli di architettura di tipo PaaS. Le applicazioni PaaS in Azure si basano in genere su costrutti specifici di Azure come i ruoli, i servizi cloud e il controller di infrastruttura. Per creare una soluzione locale per questo tipo di applicazione PaaS è necessaria un'architettura sostanzialmente diversa. Ciò potrebbe non essere fattibile dal punto di vista della gestione o dei costi.

Una soluzione ibrida per il ripristino di emergenza pone tuttavia meno ostacoli per le architetture tradizionali semplicemente trasferite nel cloud. Ciò vale per le architetture di tipo IaaS. Le applicazioni IaaS utilizzano macchine virtuali nel cloud per le quali possono esistere equivalenti diretti in locale. L'uso di reti virtuali consente inoltre di connettere macchine nel cloud a risorse di rete locali. Ciò apre diverse opportunità impossibili con le applicazioni solo PaaS. Ad esempio, SQL Server può trarre vantaggio dalle soluzioni di ripristino di emergenza quali i gruppi di disponibilità AlwaysOn e il mirroring di database. Per dettagli, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

Le soluzioni di tipo IaaS forniscono inoltre alle applicazioni locali una modalità più semplice per utilizzare Azure come opzione di failover. È possibile disporre di un'applicazione pienamente funzionante in un data center locale esistente. Se tuttavia non sono disponibili risorse sufficienti per gestire un data center separato in un'altra area geografica a fini di failover è possibile decidere di utilizzare macchine e reti virtuali per eseguire l'applicazione in Azure. Definire i processi per la sincronizzazione dei dati nel cloud. La distribuzione di Azure diventa quindi il data center secondario da utilizzare per il failover. Il data center principale rimane l'applicazione locale. Per altre informazioni sull'architettura IaaS e le relative funzionalità, vedere Macchine virtuali e Rete virtuale.

In alcune circostanze è possibile che neanche l'affidabilità del cloud Microsoft risulti sufficiente per i propri requisiti di disponibilità. L'anno scorso si sono verificate alcune gravi interruzioni di diverse piattaforme cloud, come Amazon Web Services (AWS) e Azure. Neanche i sistemi di backup meglio progettati e la migliore preparazione possono mettere al riparo dalla totale indisponibilità dell'intero cloud.

È consigliabile confrontare i requisiti di disponibilità con i costi e la complessità di una disponibilità maggiore. Eseguire un'analisi dei rischi e definire gli obiettivi RTO e RPO della soluzione. Se l'applicazione non può tollerare alcun tipo di interruzione, potrebbe essere opportuno valutare l'uso di un'altra soluzione cloud. A meno che l'intera rete Internet non smetta di funzionare contemporaneamente, un'altra soluzione cloud, ad esempio Rackspace o Amazon Web Services, continuerà a funzionare nella rara eventualità di una completa interruzione di Azure.

Come nello scenario ibrido, le distribuzioni di failover nelle architetture di ripristino di emergenza precedenti possono trovarsi anche in un'altra soluzione cloud. I siti di ripristino di emergenza in cloud alternativi devono essere utilizzati solo per soluzioni con un RTO che non ammette alcun periodo di inattività. Tenere presente che una soluzione che si avvale di un sito di ripristino di emergenza all'esterno di Azure richiede maggiore impegno per la configurazione, lo sviluppo, la distribuzione e la gestione. Risulta inoltre più difficile implementare le procedure consigliate nelle architetture tra cloud. Sebbene le piattaforme cloud si basino su concetti generali simili, le API e le architetture sono diverse. Se si dovesse decidere di suddividere il ripristino di emergenza tra piattaforme diverse, è consigliabile progettare livelli di astrazione all'interno della soluzione. In questo modo non sarà necessario sviluppare e gestire due versioni diverse della stessa applicazione per diverse piattaforme cloud in caso di emergenza. Come nello scenario ibrido, l'utilizzo delle macchine virtuali potrebbe essere più facile in questi casi che nelle progettazioni PaaS specifiche del cloud.

Alcuni modelli fin qui illustrati richiedono l'attivazione rapida delle distribuzioni offline nonché il ripristino delle parti specifiche di un sistema. L'automazione, ovvero lo scripting, supporta la possibilità di attivare le risorse su richiesta e di distribuire rapidamente le soluzioni. In questo articolo, l'automazione correlata al ripristino di emergenza corrisponde a Azure PowerShell, ma l'API REST di gestione dei servizi resta sempre un'opzione. Lo sviluppo di script agevola la gestione delle fasi del ripristino di emergenza che Azure non gestisce in modo trasparente. Ciò implica il vantaggio di produrre risultati coerenti in ogni occasione, riducendo quindi al minimo la possibilità di errore umano. La disponibilità di script di ripristino di emergenza predefiniti consente inoltre di ridurre i tempi di rigenerazione di un sistema e dei suoi componenti durante una condizione di emergenza. Quando il sito è inattivo e continua a perdere denaro non è certo il momento adatto per definire manualmente una procedura di ripristino.

Dopo aver creato gli script, è consigliabile testarli più volte dall'inizio alla fine. Dopo avere verificato le funzionalità di base, testarli in Simulazione di un'emergenza. Ciò consente di rilevare difetti negli script o nei processi.

Una procedura consigliata per l'automazione consiste nel creare un archivio di script di PowerShell per il ripristino di emergenza di Azure. Contrassegnarli e classificarli chiaramente per agevolare la ricerca. Designare una persona che gestisca il repository e il controllo delle versioni degli script. Documentarli accuratamente con spiegazioni dei parametri ed esempi di utilizzo. Accertarsi inoltre che tale documentazione sia sincronizzata con le distribuzioni di Azure. Ciò evidenzia lo scopo di disporre di una persona responsabile di tutte le parti dell'archivio.

Per poter gestire correttamente le problematiche relative a disponibilità e ripristino di emergenza, è necessario essere in grado di rilevare e diagnosticare gli errori. È necessario eseguire attività avanzate di monitoraggio di server e distribuzioni in modo da sapere rapidamente quando un sistema o alcuni suoi componenti smettono di funzionare. Parte di questa attività può essere eseguita dagli strumenti di monitoraggio dello stato complessivo del servizio cloud e delle sue dipendenze. Due strumenti Microsoft sono MetricsHub e System Center 2012 R2 (SCOM). Altri strumenti di terze parti, come AzureWatch, offrono ugualmente funzionalità di monitoraggio. AzureWatch consente di automatizzare la scalabilità. La maggior parte delle soluzioni controlla i contatori delle prestazioni chiave e la disponibilità dei servizi.

Sebbene questi strumenti siano essenziali, essi non sostituiscono la necessità di pianificare il rilevamento e la segnalazione degli errori in un servizio cloud. È necessario provvedere alla pianificazione per un utilizzo corretto della diagnostica di Azure. Contatori delle prestazioni personalizzati o voci di registro degli eventi possono ugualmente costituire componenti della strategia complessiva. In questo modo è possibile disporre di più dati in caso di errore per diagnosticare il problema e ripristinare tutte le funzionalità. Sono inoltre disponibili altre metriche che gli strumenti di monitoraggio possono utilizzare per determinare lo stato di un'applicazione. Per altre informazioni, vedere Raccogliere dati di registrazione utilizzando Diagnostica Azure. Per informazioni su come pianificare un modello di stato generale, vedere Operatore alternativo: informazioni aggiuntive per architetture cloud resilienti.

I test di simulazione prevedono la creazione di situazioni reali nell'ambiente operativo effettivo per osservare in che modo i membri del team reagiscono. Consentono inoltre di valutare l'efficienza delle soluzioni descritte nel piano di ripristino. Le simulazioni devono essere eseguite in modo che gli scenari creati non interrompano le attività aziendali effettive senza tuttavia risultare meno concreti.

Provare a progettare un tipo di "centralino" nell'applicazione per simulare manualmente problemi di disponibilità. Ad esempio, tramite uno switch software, attivare eccezioni di accesso al database per il modulo di elaborazione degli ordini causandone il malfunzionamento. Approcci semplici di questo tipo possono essere adottati per altri moduli a livello di interfaccia di rete.

Durante la simulazione vengono evidenziati eventuali problemi non gestiti in modo adeguato. Gli scenari simulati devono essere completamente controllabili. In questo modo, anche qualora il piano di ripristino avesse esito negativo, è possibile ripristinare la situazione senza causare danni significativi. È inoltre importante che i responsabili di livello più alto siano informati sui tempi e sulle modalità di esecuzione delle simulazioni. Questo piano deve includere informazioni sul tempo o sulle risorse la cui produttività potrebbe essere compromessa durante i test di simulazione. Quando si sottopone a test il proprio piano di ripristino di emergenza, è anche importante definire le modalità di valutazione dei risultati.

Esistono diverse altre tecniche utilizzabili per testare i piani di ripristino di emergenza. Tuttavia, la maggior parte di essi è costituita da varianti delle tecniche di base. L'obiettivo principale dei test consiste nel valutare la fattibilità e l'efficacia del piano di ripristino. I test del piano di ripristino di emergenza sono incentrati sui dettagli per individuare falle nel piano di base.

Riepiloghiamo gli argomenti essenziali trattati in questo articolo. Questo riepilogo rappresenterà un elenco di controllo di cui tenere conto ai fini della pianificazione della disponibilità e del ripristino di emergenza. Si tratta di procedure consigliate utili per i clienti che desiderano implementare una soluzione efficiente. Questo tipo di soluzione è realmente efficace per il ripristino tempestivo e corretto in seguito a errori di sistema.

  1. Condurre una valutazione dei rischi per ogni applicazione in quanto ciascuna di esse può presentare requisiti diversi. Alcune applicazioni sono più importanti di altre, il che giustifica i costi aggiuntivi necessari per progettare il ripristino di emergenza.

  2. Utilizzare queste informazioni per definire gli obiettivi RTO e RPO di ogni applicazione.

  3. Progettare nell'ottica del rischio di errori, a partire dall'architettura dell'applicazione.

  4. Implementare le procedure consigliate per la disponibilità elevata senza rinunciare all'equilibro tra costi, complessità e rischio.

  5. Implementare i piani e i processi di ripristino di emergenza.

    1. Valutare gli errori, da quelli a livello di modulo fino a quelli che compromettono completamente il cloud.

    2. Stabilire strategie di backup per tutti i dati di riferimento e transazionali.

    3. Scegliere un'architettura di ripristino di emergenza a più siti.

  6. Definire un proprietario specifico per i processi, l'automazione e i test del ripristino di emergenza. Il proprietario deve gestire l'intero processo.

  7. Documentare i processi in modo che siano facilmente ripetibili. Sebbene vi sia un proprietario, più persone devono essere in grado di comprendere e seguire i processi in caso di emergenza.

  8. Formare il personale in merito all'implementazione del processo.

  9. Utilizzare le simulazioni di ripristino a fini sia di formazione sia di convalida del processo.

Quando si verificano problemi hardware o software in Azure, è possibile adottare tecniche e strategie di gestione diverse da quelle utilizzate in caso di problemi nei sistemi locali. Ciò dipende soprattutto dal fatto che le soluzioni cloud presentano in genere più dipendenze dall'infrastruttura nel data center e vengono gestite come servizi distinti. Gli errori parziali devono essere gestiti mediante tecniche per la disponibilità elevata. Per gestire errori più gravi, dovuti probabilmente a un evento di emergenza, utilizzare strategie di ripristino di emergenza.

Azure rileva e gestisce molti errori, ma esistono molti tipi di errori che richiedono strategie specifiche dell'applicazione. È necessario prepararsi attivamente per gestire gli errori di applicazioni, servizi e dati.

Quando si crea un piano di disponibilità e ripristino di emergenza dell'applicazione, tenere conto delle conseguenze aziendali dell'errore dell'applicazione. La definizione di processi, criteri e procedure per il ripristino di sistemi critici in seguito a eventi catastrofici richiede tempo, pianificazione e impegno. L'operazione, inoltre, non si esaurisce con la definizione dei piani. È necessario analizzare, testare e migliorare continuamente i piani in base al portafoglio di applicazioni, alle esigenze aziendali e alle tecnologie disponibili. Azure offre nuove funzionalità e pone nuove problematiche per la creazione di applicazioni affidabili in grado di far fronte agli errori.

Vedere anche

Mostra:
© 2014 Microsoft