VENDITE: 1-800-867-1389

Informazioni tecniche sulla continuità aziendale di Azure

Aggiornamento: marzo 2015

Autori: Patrick Wickline, Jason Roth

Collaboratori e revisori: Luis Carlos Vargas Herring, Drew McDaniel, David Magar, Ganesh Srinivasan, Milan Gada, Nir Mashkowski ,Harsh Mittal, Sasha Nosov, Selcin Turkarslan, Cephas Lin, Cheryl McGuire, Bill Mathers, Mandi Ohlinger, Sidney Higa, Michael Green, Heidi Steen, Matt Winkler, Shayne Burgess, Larry Franks, Brad Severtson, Yavor Georgiev, Glenn Gailey, Tim Ammann, Ruppert Koch, Seth Manheim, Abhinav Gupta, Steve Danielson, Corey Sanders, John Deutscher

Per soddisfare i requisiti di disponibilità elevata e ripristino di emergenza è necessario avere una conoscenza tecnica approfondita delle funzionalità della piattaforma cloud ed essere in grado di creare correttamente l'architettura di un servizio distribuito. In questo documento vengono illustrate le funzionalità e le limitazioni della piattaforma Azure in relazione alla continuità aziendale. Vengono anche riportate informazioni sui modelli di architettura e progettazione, sebbene non costituiscano l'argomento principale. Per informazioni aggiuntive relative alla progettazione è necessario consultare il materiale nell'altra sezione Risorse aggiuntive.

Le informazioni sono organizzate nelle sezioni seguenti:

  • 1. Recupero da errori locali : durante i picchi di carico si possono verificare errori ai componenti hardware (ad esempio unità, server e dispositivi di rete) o si possono esaurire le risorse disponibili. Questa sezione descrive le funzionalità fornite da Azure per gestire la disponibilità elevata in queste condizioni.

  • 2. Recupero dalla perdita di un'area di Azure: errori generalizzati sono rari ma possibili. Intere aree possono risultare isolate a causa di errori di rete oppure fisicamente danneggiate a causa di calamità naturali. In questa sezione viene illustrato come utilizzare le funzionalità di Azure per creare applicazioni utilizzabili in aree geograficamente diverse.

  • 3. Recupero da locale a Azure: il cloud modifica in modo significativo l'economia del ripristino di emergenza consentendo alle organizzazioni di usare Azure per creare un secondo sito per il recupero. Questa operazione può essere eseguita a un costo decisamente ridotto rispetto a quello di compilazione e gestione di un data center secondario. In questa sezione vengono illustrate le funzionalità fornite da Azure per estendere un data center locale nel cloud.

  • 4. Recupero dal danneggiamento dei dati o dall'eliminazione accidentale: le applicazioni possono contenere bug che danneggiano i dati e gli operatori possono erroneamente eliminare dati importanti. In questa sezione vengono illustrate le funzionalità fornite da Azure per il backup dei dati e il ripristino a una temporizzazione precedente.

  • 5. Risorse aggiuntive: altre importanti risorse relative alla disponibilità e al ripristino di emergenza in Azure.

Le due principali condizioni che possono compromettere la disponibilità delle applicazioni sono la presenza di dispositivi guasti, come unità e server, e l'esaurimento di risorse cruciali, ad esempio le risorse di calcolo in condizioni di picchi di carico. Azure fornisce una combinazione di funzionalità di gestione delle risorse, elasticità, bilanciamento del carico e partizionamento per abilitare la disponibilità elevata in queste condizioni. Alcune di queste funzionalità vengono eseguite automaticamente per tutti i servizi cloud, ma talvolta è necessario che lo sviluppatore dell'applicazione esegua delle operazioni aggiuntive per ottenere i vantaggi appropriati.

Tutti i servizi cloud ospitati da Azure sono raccolte di uno o più ruoli di lavoro o Web. È possibile eseguire una o più istanze di un ruolo contemporaneamente. Il numero delle istanze è determinato dalla configurazione. Le istanze del ruolo vengono monitorate e gestite con un componente denominato controller di infrastruttura. Il controller di infrastruttura automaticamente rileva gli errori software e hardware ed elabora una risposta.

  • Ogni istanza del ruolo viene eseguita in una macchina virtuale (VM) dedicata e comunica con il controller di infrastruttura tramite un agente guest. L'agente guest raccoglie le metriche dei nodi e delle risorse, tra cui l'uso della macchina virtuale, lo stato, i log, l'uso delle risorse, le eccezioni e le condizioni di errore. Tramite il controller di infrastruttura vengono eseguite query sull'agente guest a intervalli configurabili e viene riavviata la macchina virtuale in caso di mancata risposta da parte dell'agente guest.

  • In caso di errore hardware, tramite il controller di infrastruttura associato tutte le istanze del ruolo interessate vengono spostate in un nuovo nodo hardware e la rete viene riconfigurata per indirizzare il traffico in base alla nuova impostazione.

Per usare al meglio queste funzionalità, gli sviluppatori devono essere certi che nessun ruolo del servizio usi l'archiviazione dello stato nelle istanze del ruolo. È invece necessario accedere a tutti i dati persistenti dall'archiviazione durevole, ad esempio dai servizi di archiviazione di Azure o dal Database SQL di Azure. In questo modo le richieste possono essere gestite da tutti i ruoli. Le istanze del ruolo possono venire interrotte in qualsiasi momento senza creare incoerenze nello stato temporaneo o persistente del servizio.

Il requisito di archiviare lo stato esternamente ai ruoli comporta diverse implicazioni. Ad esempio, tutte le modifiche relative a una tabella di archiviazione di Azure devono essere applicate in una singola transazione di gruppo di entità, se possibile. Tuttavia, non è sempre possibile apportare tutte le modifiche in un'unica transazione. È necessario prestare un'attenzione particolare per essere certi che gli errori dell'istanza del ruolo non causino problemi quando interrompono operazioni a esecuzione prolungata che interessano due o più aggiornamenti allo stato persistente del servizio. Se un altro ruolo ritenta l'esecuzione dell'operazione, è necessario saper anticipare e gestire il caso in cui il lavoro è stato parzialmente completato.

Ad esempio, in un servizio che esegue il partizionamento dei dati in più archivi, se un ruolo di lavoro viene arrestato durante la rilocazione di una partizione, è possibile che la rilocazione della partizione non venga completata o che venga ripetuta dall'inizio da un altro ruolo di lavoro, causando potenzialmente dati orfani o danneggiati. Per evitare problemi, le operazioni a esecuzione prolungata devono essere idempotenti, ovvero ripetibili senza effetti collaterali, e/o riavviabili in modalità incrementale, ossia in grado di continuare dal punto di errore più recente.

  • Per essere idempotente, un'operazione a esecuzione prolungata deve produrre il medesimo risultato indipendentemente da quante volte viene eseguita e anche in caso di interruzione durante l'esecuzione.

  • Per essere riavviabile in modalità incrementale, un'operazione a esecuzione prolungata deve essere costituita da una sequenza di operazioni atomiche più piccole e il relativo stato di avanzamento deve essere registrato nell'archiviazione durevole, in modo che ogni chiamata successiva venga accettata all'arresto del predecessore.

Infine, tutte le operazioni a esecuzione prolungata devono essere richiamate ripetutamente finché non vengono completate. Ad esempio, è possibile che un'operazione di provisioning venga posizionata in una coda di Azure e rimossa dalla coda da un ruolo di lavoro solo quando viene completata. Potrebbe essere necessaria un'operazione di Garbage Collection per pulire i dati creati dalle operazioni interrotte.

Il numero iniziale delle istanze in esecuzione per ogni ruolo è determinato nella configurazione di ogni ruolo. Gli amministratori configurano inizialmente ogni ruolo per l'esecuzione di due o più istanze, in base al carico previsto. Tuttavia, è possibile che il numero delle istanze del ruolo vengano ridotto o aumento in base ai cambiamenti dei modelli d'uso. Questa operazione può essere eseguita tramite il Portale di Azure, Windows PowerShell, l'API di gestione del servizio o strumenti di terze parti. Il controller di infrastruttura automaticamente effettua il provisioning delle nuove istanze e le inserisce nel bilanciamento del carico per il ruolo in questione.

Con la scalabilità automatica di Azure (anteprima) è possibile abilitare in Azure la scalabilità automatica dei ruoli in base al carico. La scalabilità automatica può anche essere incorporata a livello di codice e configurata per un servizio cloud tramite un framework, ad esempio il blocco di applicazioni per la scalabilità automatica.

I controller di infrastruttura usano due tipi di partizioni: vale a dire i domini di aggiornamento e di errore.

  • Un dominio di aggiornamento viene utilizzato per aggiornare le istanze del ruolo di un servizio nei gruppi. Azure distribuisce le istanze del servizio in più domini di aggiornamento. Nel caso di un aggiornamento sul posto, il controller di infrastruttura interrompe tutte le istanze del dominio di aggiornamento, le aggiorna e quindi le riavvia prima di passare al dominio di aggiornamento successivo. In tal modo si evita che l'intero servizio diventi non disponibile durante il processo di aggiornamento.

  • Un dominio di errore definisce i punti di errore potenziali per la rete o l'hardware. Nel caso di un ruolo con più istanze, il controller di infrastruttura assicura che le istanze vengano distribuite in più domini di errore per impedire il verificarsi di errori hardware isolati a causa dell'interruzione del servizio. Qualsiasi rischio di errore del server e del cluster in Azure è governato dai domini di errore.

In base al contratto di servizio di Azure, Microsoft garantisce che durante la distribuzione di due o più istanze di ruolo Web in domini di errore o di aggiornamento diversi, i ruoli disporranno di connettività esterna per almeno il 99,95% del tempo. Diversamente dai domini di aggiornamento, non è possibile controllare il numero dei domini di errore. Azure automaticamente alloca i domini di errore e distribuisce le istanze del ruolo tra i domini. Almeno le prime due istanze di ogni ruolo vengono posizionate in domini di aggiornamento e di errori diversi per assicurare che ogni ruolo con almeno due istanze soddisfi il contratto di servizio. Questa condizione è illustrata nel diagramma seguente.

Isolamento di dominio errato (vista semplificata)

Tutto il traffico in ingresso destinato a un ruolo Web passa tramite un bilanciamento del carico senza stato che distribuisce le richieste client tra le istanze del ruolo. Le singole istanze del ruolo non hanno indirizzi IP pubblici e non sono direttamente indirizzabili tramite Internet. I ruoli Web sono senza stato in modo che tutte le richieste client possano essere indirizzate a qualsiasi istanza del ruolo. Un evento StatusCheck viene generato ogni 15 secondi. L'evento può essere usato per indicare se il ruolo è pronto a ricevere il traffico oppure se è occupato e deve essere escluso dalla rotazione del bilanciamento del carico.

Le macchine virtuali di Azure differiscono dai ruoli di calcolo di PaaS per diversi aspetti in relazione alla disponibilità elevata. In alcuni casi, è necessario eseguire operazioni aggiuntive al fine di garantire la disponibilità elevata.

Diversamente dalle istanze del ruolo PaaS, i dati archiviati nelle unità di macchina virtuale sono persistenti anche quando la macchina virtuale viene rilocata. Le macchine virtuali di Azure usano i dischi di macchina virtuale disponibili come BLOB in Archiviazione di Azure. Grazie alle funzionalità di disponibilità del Servizio di archiviazione Azure, i dati archiviati nelle unità di una macchina virtuale sono anche a disponibilità elevata. L'unità D: costituisce l'unica eccezione a questa regola. Per questo motivo, l'unità D: l'unità di archiviazione fisica del server rack che ospita la macchina virtuale e, se questa viene riciclata, tutti i dati dell'unità vengono persi. Per questo motivo, l'unità D: è destinata esclusivamente all'archiviazione temporanea.

Azure a livello nativo riconosce i livelli di un'applicazione PaaS (ruolo di lavoro e ruolo Web) e li distribuisce correttamente tra i domini di aggiornamento e di errore. I livelli delle applicazioni IaaS devono essere invece definiti manualmente usando i set di disponibilità. I set di disponibilità sono necessari per un contratto di servizio in IaaS.

Set di disponibilità per le macchine virtuali di Microsoft Azure

Nel diagramma riportato in precedenza, il livello IIS e il livello SQL sono assegnati a set di disponibilità diversi. In tal modo si garantisce che tutte le istanze di ogni livello dispongano della ridondanza dell'hardware tramite la distribuzione in domini di errore e che non vengano interrotte durante l'aggiornamento.

Se il traffico viene distribuito tra le macchine virtuali, è necessario raggruppare le macchine virtuali in un servizio cloud e bilanciare il carico tra uno specifico endpoint UDP o TCP. Per altre informazioni, vedere Bilanciamento del carico delle macchine virtuali. Se le macchine virtuali ricevono l'input da un'altra origine, ad esempio un meccanismo di accodamento, il bilanciamento del carico non è necessario. Il bilanciamento del carico usa un controllo di integrità di base per determinare se il traffico deve essere inviato al nodo. È inoltre possibile creare i probe per implementare le metriche di integrità specifiche dell'applicazione che determinano se la macchina virtuale deve ricevere il traffico.

Archiviazione di Azure è il punto di riferimento per i dati durevoli in Azure e fornisce l'archiviazione di BLOB, tabelle, code dischi di macchina virtuale. Usa una combinazione di funzionalità di replica e gestione delle risorse per assicurare la disponibilità elevata in un singolo data center. Tramite il contratto di servizio relativo alla disponibilità di Archiviazione di Azure viene garantito che, per almeno il 99,9% del tempo, le richieste formattate correttamente per aggiungere, aggiornare, leggere ed eliminare dati vengono elaborate in modo appropriato e che per gli account di archiviazione è disponibile la connettività al gateway Internet.

La durabilità dei dati viene semplificata da Archiviazione di Azure che mantiene più copie di tutti i dati in unità diverse, dislocate all'interno dell'area in sottosistemi di archiviazione fisici completamente indipendenti. I dati vengono replicati in modo sincrono e viene eseguito il commit di tutte le copie prima che la scrittura venga confermata. Archiviazione di Azure è fortemente coerente, ovvero le letture vengono garantite per riflettere le scritture più recenti. Le copie dei dati inoltre vengono analizzate continuamente per rilevare e ripristinare eventuali bit danneggiati, una minaccia all'integrità dei dati archiviati spesso trascurata. I servizi usufruiscono della replica semplicemente usando Archiviazione di Azure. Non è necessario che lo sviluppatore esegua altre attività per il recupero da un errore locale.

Le dimensione degli account di archiviazione creati dopo il 7 giugno 2012 possono incrementare fino a 200 TB (il massimo precedente era 100 TB). Se è necessario spazio aggiuntivo, le applicazioni devono essere progettate per usare più account di archiviazione.

Il disco di una macchina virtuale viene archiviato come BLOB di pagine nel Servizio di archiviazione Azure, offrendo in tal modo le stesse proprietà di scalabilità e durabilità dell'archiviazione BLOB. Questa progettazione rende persistenti i dati di un disco di macchina virtuale anche se si verifica un errore nel server che esegue la macchina virtuale e la macchina virtuale deve essere riavviata in un altro server.

Database SQL di Microsoft Azure fornisce un database come servizio, consentendo alle applicazioni di eseguire rapidamente operazioni di provisioning, inserimento dei dati ed esecuzione di query nei database relazionali. Offre inoltre molte delle funzionalità comuni di SQL Server, eliminando però le attività correlate all'hardware, alla configurazione, all'applicazione di patch e alla resilienza.

noteNota
Database SQL di Azure non è funzionalmente equivalente a SQL Server ed è progettato per soddisfare una serie di requisiti diversi, esclusivi per le applicazioni cloud (scalabilità elastica, database come servizio per la riduzione dei costi di manutenzione e così via). Per altre informazioni, vedere il post relativo al confronto tra SQL Server in una macchina virtuale di Azure e un database SQL.

Database SQL di Azure offre la resilienza predefinita per l'errore a livello di nodo. Tutte le operazioni di scrittura in un database vengono replicate automaticamente in due o più nodi in background usando una tecnica di commit basata su quorum. Tramite il nodo primario e almeno uno secondario deve essere verificato che l'attività venga scritta nel log delle transazioni prima che quest'ultima venga ritenuta corretta e che tramite essa venga restituito un valore. In caso di errore del nodo viene eseguito automaticamente il failover del database in una delle repliche secondarie. Ciò provoca un'interruzione temporanea della connessione per le applicazioni client. Per questo motivo tutti i client Database SQL di Microsoft Azure devono implementare un metodo di gestione temporanea della connessione. Per altre informazioni, vedere l'articolo relativo all'uso del blocco applicazione per la gestione degli errori temporanei con SQL Azure.

Ogni database, quando creato, è configurato con un limite massimo di dimensioni. Le dimensioni massime attualmente disponibili corrispondono a 150 GB. Quando un database raggiunge il limite massimo delle dimensioni, i comandi aggiuntivi INSERT o UPDATE vengono rifiutati. L'esecuzione di query e l'eliminazione dei dati sono però operazioni ancora possibili.

In un database, Database SQL di Microsoft Azure usa un'infrastruttura per gestire le risorse. Tuttavia, per rilevare gli errori usa una topologia ad anello anziché un controller di infrastruttura. Ogni replica in un cluster include due elementi adiacenti che sono responsabili del rilevamento dei casi di interruzione. Quando una replica viene interrotta, gli elementi adiacenti attivano un agente di riconfigurazione per ricreare la replica in un altro computer. La limitazione delle richieste del motore è fornita per garantire che un server logico non utilizzi troppe risorse di un computer o superi i limiti fisici del computer.

Se la richiesta dell'applicazione supera il limite del database di 150 GB è necessario implementare un approccio con scalabilità orizzontale. La scalabilità orizzontale con Database SQL di Microsoft Azure viene eseguita manualmente tramite il partizionamento, noto anche come partizionamento orizzontale, dei dati in più Database SQL di Azure. Questo approccio con scalabilità orizzontale offre l'opportunità di ottenere un aumento dei costi quasi lineare con la scalabilità. La crescita o capacità elastica su richiesta può aumentare con costi incrementali in base alle esigenze dal momento che la fatturazione dei database viene effettuata in base alle dimensioni medie usate al giorno e non in base alle dimensioni massime possibili.

Installando SQL Server 2014 in Macchine virtuali di Azure (IaaS), si possono usare le funzionalità di disponibilità tradizionali di SQL Server, ad esempio i gruppi di disponibilità AlwaysOn o il mirroring del database. La macchina virtuale, l'archiviazione e la rete di Azure hanno caratteristiche operative diverse rispetto a un'infrastruttura IT locale non virtualizzata. Per una corretta implementazione di una soluzione HADR SQL Server in Azure è necessario capire queste differenze e progettare una soluzione adeguata.

Quando si implementa una soluzione a disponibilità elevata in Azure, il set di disponibilità in Azure consente di posizionare i nodi a disponibilità elevata in domini di errore e di aggiornamento separati. Per chiarire, il set di disponibilità è un concetto di Azure. Come procedura consigliata, verificare che i database siano effettivamente a disponibilità elevata, se si usano i gruppi di disponibilità AlwaysOn, il mirroring del database o altro. Se non si esegue questa procedura consigliata, si potrebbe presupporre erroneamente che il sistema sia a disponibilità elevata, mentre in realtà i nodi possono bloccarsi tutti contemporaneamente perché sono posizionati nello stesso dominio di errore nel data center di Azure. Questa raccomandazione non è applicabile con il log shipping poiché, trattandosi di una funzionalità di ripristino di emergenza, è necessario assicurarsi che i server siano in esecuzione in posizioni (aree) separate del data center di Azure. Queste posizioni del data center sono per definizione domini di errore separati.

Per collocare le macchine virtuali di Azure nello stesso set di disponibilità, è necessario distribuirle nello stesso servizio cloud. Solo i nodi dello stesso servizio cloud possono partecipare allo stesso set di disponibilità. Inoltre, le macchine virtuali devono trovarsi nella stessa rete virtuale per garantire che conservino l'IP anche dopo il ripristino del servizio, evitando in tal modo i tempi di aggiornamento del DNS.

È possibile disporre di una soluzione a disponibilità elevata per i database di SQL Server in Azure usando i gruppi di disponibilità AlwaysOn o il mirroring del database.

Nel diagramma seguente viene illustrata l'architettura dei gruppi di disponibilità AlwaysOn in esecuzione in Macchine virtuali di Azure. Il diagramma è stato preso dall'articolo tecnico relativo a questo argomento (Disponibilità elevata e ripristino di emergenza per SQL Server in Macchine virtuali di Azure).

Gruppi di disponibilità AlwaysOn in Microsoft Azure

È anche possibile eseguire il provisioning automatico della distribuzione di un gruppo di disponibilità AlwaysOn end-to-end nelle macchine virtuali di Azure usando il modello AlwaysOn disponibile nel portale di Microsoft Azure. Per altre informazioni, vedere il post di blog relativo all'offerta per SQL Server AlwaysOn nella raccolta del portale di Microsoft Azure.

Nel diagramma seguente viene illustrato l'uso del mirroring del database in Macchine virtuali di Azure. Il diagramma è stato preso dall'articolo tecnico Disponibilità elevata e ripristino di emergenza per SQL Server in Macchine virtuali di Azure.

Mirroring del database in Microsoft Azure
noteNota
Si noti che in entrambe le architetture è richiesto un controller di dominio. Tuttavia, con il mirroring del database è possibile usare i certificati del server per eliminare l'esigenza del controller di dominio.

I servizi cloud di Azure sono compilati su Azure e quindi usano le funzionalità della piattaforma descritte in precedenza per il recupero da errori locali. In alcuni casi, sono disponibili determinate azioni che si possono intraprendere per aumentare la disponibilità dello scenario specifico.

Servizio Access Control (ACS) 2.0 esegue il backup di tutti gli spazi dei nomi una volta al giorno e li archivia esternamente in un luogo sicuro. Quando il personale addetto al funzionamento di ACS determina che si è verificata una perdita di dati irreversibile in uno dei data center di regione di ACS, ACS tenterà di recuperare le sottoscrizioni dei clienti ripristinando il backup più recente. A causa della frequenza dei backup, è possibile che si verifichi una perdita di dati fino a 24 ore. Per altre informazioni, vedere Servizio Access Control (ripristino di emergenza).

Per ridurre gli effetti di un'interruzione temporanea di Azure Service Bus, è opportuno creare una coda durevole lato client. In tal modo si usa temporaneamente un meccanismo di archiviazione locale alternativo per archiviare i messaggi che non possono essere inseriti nella coda di Service Bus. L'applicazione può includere l'impostazione per la gestione dei messaggi archiviati temporaneamente una volta che il servizio viene ripristinato. Per altre informazioni, vedere Procedure consigliate per il miglioramento delle prestazioni tramite la messaggistica negoziata di Service Bus. Per altre informazioni, vedere Service Bus (ripristino di emergenza).

Servizi mobili di Azure include due fattori di disponibilità. Il backup regolare di Database SQL di Azure associato al servizio mobile e il backup degli script del servizio mobile. Per altre informazioni, vedere l'articolo relativo al recupero del servizio mobile in caso di emergenza. Se si verifica un'interruzione temporanea dei servizi mobili, potrebbe essere necessario usare temporaneamente un data center alternativo di Azure. Per altre informazioni, vedere Servizi mobili (ripristino di emergenza).

I dati associati a HDInsight vengono archiviati per impostazione predefinita nel servizio di archiviazione BLOB di Azure che applica le proprietà di durabilità e alta disponibilità specificate in Archiviazione di Azure. L'elaborazione a più nodi associata ai processi Hadoop MapReduce viene eseguita in un file system distribuito Hadoop temporaneo (HDFS) fornito quando necessario da HDInsight. I risultati di un processo MapReduce vengono archiviati per impostazione predefinita anche nel servizio di archiviazione BLOB di Azure, in modo che i dati elaborati siano durevoli e rimangano a disponibilità elevata una volta eseguito il deprovisioning del cluster Hadoop. Per altre informazioni, vedere HDInsight (ripristino di emergenza).

 

Servizio/Area Elenco di controllo

Calcolo (PaaS)

  • Configurare almeno due istanze per ogni ruolo.

  • Rendere persistente lo stato nell'archiviazione durevole, non nelle istanze del ruolo.

  • Gestire correttamente l'evento StatusCheck.

  • Eseguire il wrapping delle modifiche correlate nelle transazioni quando possibile.

  • Verificare che le attività del ruolo di lavoro siano idempotenti e riavviabili.

  • Continuare a richiamare le operazioni finché non vengono completate.

  • Considerare le strategie di scalabilità automatica.

Macchine virtuali (IaaS)

  • Non usare l'unità D: per l'archiviazione permanente.

  • Raggruppare i computer di un livello del servizio in un set di disponibilità.

  • Configurare il bilanciamento del carico e i probe facoltativi.

Archiviazione

  • Usare più account di archiviazione quando la larghezza di banda o i dati superano le quote.

Database SQL

  • Implementare criteri di riesecuzione per gestire gli errori temporanei.

  • Usare il partizionamento o il partizionamento orizzontale come strategia di scalabilità orizzontale.

SQL Server 2014 nelle macchine virtuali (IaaS)

  • Applicare le raccomandazioni precedenti indicate per le macchine virtuali.

  • Usare le funzionalità di disponibilità elevata di SQL Server, ad esempio AlwaysOn.

Servizio Access Control (disponibilità)

  • Nessun passaggio di disponibilità aggiuntivo per gli errori locali.

Service Bus (disponibilità)

  • Creare una coda durevole lato client come backup.

Servizi mobili (disponibilità)

  • Eseguire regolarmente il backup di Database SQL di Azure associato ai servizi mobili.

  • Eseguire il backup degli script dei servizi mobili.

HDInsight (disponibilità)

  • Nessun passaggio di disponibilità aggiuntivo per gli errori locali.

Azure viene diviso fisicamente e logicamente in unità chiamate aree. Un'area è costituita da uno o più data center in stretta vicinanza. Attualmente Azure dispone di otto aree (4 in America del nord, 2 in Asia e 2 in Europa).

In rare circostanze le funzionalità di un'intera area possono diventare inaccessibili, ad esempio a causa di errori di rete o di una perdita totale per calamità naturali. In questa sezione vengono illustrate le funzionalità di Azure destinate alla creazione di applicazioni distribuite tra le aree. Le aree sono progettate per ridurre la possibilità che l'errore di 'area possa riguardare anche le altre.

La distribuzione delle istanze di calcolo nelle aree viene eseguita tramite la creazione di un servizio cloud separato in ogni area di destinazione e la pubblicazione del pacchetto di distribuzione in ogni servizio cloud. Tuttavia, la distribuzione del traffico tra i servizi cloud nelle diverse aree deve essere implementata dallo sviluppatore dell'applicazione o con un servizio di gestione del traffico.

La determinazione del numero delle istanze del ruolo di riserva da distribuire in anticipo per il ripristino di emergenza è un aspetto importante della pianificazione delle capacità. Una distribuzione secondaria completa assicura che la capacità sia già disponibile quando necessaria anche se i costi risultano effettivamente raddoppiati. Un modello comune è quello di usare una piccola distribuzione secondaria sufficiente a eseguire i servizi importanti. È consigliabile creare almeno una piccola distribuzione secondaria per riservare la capacità e per verificare la configurazione dell'ambiente secondario.

noteNota
la quota di sottoscrizione non è una garanzia di capacità. La quota è semplicemente un limite di credito. Per garantire la capacità è necessario che il numero di ruoli richiesto sia definito nel modello del servizio e che i ruoli siano distribuiti.

Per bilanciare il carico del traffico tra le aree è richiesto l'uso di una soluzione di gestione del traffico. È possibile avvalersi del servizio gestione traffico di Azure. È inoltre possibile usare i servizi di terze parti che forniscono funzionalità simili per la gestione del traffico.

Molte strategie alternative sono disponibili per implementare il calcolo distribuito tra le aree. Queste devono essere personalizzate in base ai requisiti aziendali specifici e alle circostanze dell'applicazione. A un livello elevato, gli approcci possono essere suddivisi in tre categorie:

  • Ridistribuzione in caso di emergenza: con questo approccio l'applicazione viene ridistribuita da zero al momento dell'emergenza. È adatto per le applicazioni non critiche che non richiedono un tempo di recupero garantito.

  • Riserva Warm (attiva/passiva): viene creato un servizio ospitato secondario in un'area alternativa e, per garantire la capacità minima, vengono distribuiti i ruoli, sebbene non ricevano il traffico di produzione. Questo approccio è utile per le applicazioni che non sono state progettate per distribuire il traffico tra le aree.

  • Riserva Hot (attiva/attiva): l'applicazione è progettata per ricevere il carico di produzione in più aree. I servizi cloud di ogni area possono essere configurati per una capacità superiore al necessario per scopi di ripristino di emergenza. In alternativa, i servizi cloud possono eseguire la scalabilità orizzontale necessaria al momento di un'emergenza e di un failover. Questo approccio richiede un investimento sostanziale nella progettazione delle applicazione, ma presenta vantaggi significativi incluso un tempo di recupero contenuto e garantito, il test continuo di tutte le posizioni di recupero e un uso efficiente della capacità.

Una descrizione esaustiva della progettazione distribuita esula dall'argomento del presente documento. Nei seguenti documenti vengono fornite informazioni aggiuntive relative a questi scenari.

Il recupero delle macchine virtuali IaaS è simile al recupero del calcolo PaaS sotto molti aspetti, tuttavia esistono delle importanti differenze perché le macchine virtuali IaaS sono costituite da macchine virtuali e da dischi di macchina virtuale.

  • Uso dell'API per la copia di BLOB per duplicare i dischi di macchina virtuale: per creare macchine virtuali in più aree è necessario copiarne i dischi nell'area alternativa. Dal momento che i dischi di macchina virtuale sono in effetti dei BLOB, questa operazione può essere eseguita usando l'API per la copia di BLOB standard.

  • Separazione del disco dei dati dal disco del sistema operativo: è importante tenere in considerazione che per le macchine virtuali IaaS non è possibile cambiare il disco del sistema operativo senza ricreare la macchina virtuale. Non si tratta di un problema se la strategia di recupero prevede la ridistribuzione dopo l'emergenza. Tuttavia, potrebbe essere un problema se si usa l'approccio di riserva Warm per riservare la capacità. Per implementare questo approccio correttamente è necessario che il disco corretto del sistema operativo venga distribuito nel percorso primario e secondario e che i dati dell'applicazione vengano archiviati in un'unità separata. Se possibile, usare una configurazione standard del sistema operativo che può essere fornita per entrambi i percorsi. Dopo un failover è necessario quindi collegare l'unità dei dati alle macchine virtuali IaaS esistenti nel controller di dominio secondario. Usare l'API CopyBlob per copiare gli snapshot dei dischi dei dati in un sito remoto.

  • Possibili problemi di coerenza dopo un failover geografico di più dischi di macchina virtuale: i dischi di macchina virtuale vengono implementati come BLOB del servizio di archiviazione di Azure e hanno la stessa caratteristica di replica geografica (vedere di seguito). Lo stato dei dischi di macchina virtuale sarà coerente all'arresto anomalo dopo un failover geografico, tuttavia non vi sono garanzie di coerenza tra i dischi perché la replica geografica è asincrona e opera in modo indipendente. In alcuni casi questo potrebbe rappresentare un problema, ad esempio in caso di striping del disco). In questi casi, è possibile che si debbano eseguire operazioni aggiuntive per ripristinare la coerenza dopo un failover geografico. Per assicurare la correttezza dei backup, è necessario usare un prodotto di backup come Data Protection Manager per eseguire il backup e il ripristino dei dati dell'applicazione.

In Azure, i BLOB, le tabelle, le code e i dischi di macchina virtuale vengono tutti sottoposti alla replica geografica per impostazione predefinita. Questa funzionalità, che prende il nome di archiviazione con ridondanza geografica (GRS), replica i dati di archiviazione in un determinato data center a centinaia di chilometri distanza, in un'area geografica specifica. È progettata per offrire disponibilità aggiuntiva in caso di emergenza di un data center principale. Microsoft può quindi controllare quando si verifica il failover, che è limitato alle principali emergenze in cui la posizione primaria originale viene ritenuta non recuperabile in una quantità di tempo ragionevole. In alcuni scenari può trattarsi di diversi giorni. I dati vengono in genere replicati entro pochi minuti, anche se l'intervallo di sincronizzazione non rientra ancora in un contratto di servizio.

In caso di failover geografico non si verificano cambiamenti per l'accesso all'account (l'URL e la chiave dell'account non cambiano), tuttavia l'account di archiviazione si troverà in un'area diversa dopo il failover e questo può avere impatto sulle applicazioni che richiedono affinità di area con l'account di archiviazione. Anche per i servizi e le applicazioni che non richiedono un account di archiviazione nello stesso data center, i costi associati alla larghezza di banda e alla latenza tra data center possono costituire un valido motivo per spostare temporaneamente il traffico nell'area di failover. Ciò potrebbe risultare utile in una strategia globale di ripristino di emergenza.

Oltre al failover automatico fornito dalla funzionalità GRS, con Azure è stato introdotto anche un servizio che offre l'accesso in lettura a una copia dei dati personali in un percorso di archiviazione secondario. Questa funzionalità viene denominata Archiviazione con ridondanza geografica e accesso in lettura (RA-GRS).

Per altre informazioni sulle funzionalità di anteprima per l'archiviazione con ridondanza geografica e l'archiviazione con ridondanza geografica e accesso in lettura, vedere Opzioni di ridondanza di Archiviazione di Azure e Archiviazione con ridondanza geografica e accesso in lettura.

È importante conoscere dove i dati vengono replicati geograficamente per sapere dove distribuire le altre istanze dei dati che richiedono affinità di area con l'archiviazione. Nella tabella seguente vengono illustrate le associazioni di posizioni primarie e secondarie:

 

Principale Secondario

Stati Uniti centro-settentrionali

Stati Uniti centro-meridionali

Stati Uniti centro-meridionali

Stati Uniti centro-settentrionali

Stati Uniti orientali

Stati Uniti occidentali

Stati Uniti occidentali

Stati Uniti orientali

Europa settentrionale

Europa occidentale

Europa occidentale

Europa settentrionale

Asia sudorientale

Asia orientale

Asia orientale

Asia sudorientale

Cina orientale

Cina settentrionale

Cina settentrionale

Cina orientale

Brasile meridionale

Stati Uniti centro-meridionali

La replica geografica è inclusa nel prezzo corrente di Archiviazione di Azure ed è denominata archiviazione con ridondanza geografica. Se non si desidera che i dati vengano sottoposti alla replica geografica è possibile disabilitare la replica geografica per l'account. Questa opzione è denominata archiviazione con ridondanza locale e viene addebitata a un prezzo scontato rispetto all'archiviazione sottoposta a replica geografica.

Quando si verifica un failover geografico viene inserito un post nel dashboard dell'integrità del servizio di Azure, tuttavia le applicazioni possono implementare metodi di rilevamento automatici monitorando l'area geografica dell'account di archiviazione. Questo approccio può essere usato per attivare altre operazioni di recupero, ad esempio l'attivazione delle risorse di calcolo nell'area geografica in cui viene spostata l'archiviazione che può essere individuata tramite una query dall'API di gestione del servizio usando Ottenere le proprietà dell'account di archiviazione. Le proprietà rilevanti sono:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

  • Come descritto nella sezione relativa ai dischi di macchina virtuale, non si garantisce la coerenza dei dati tra i dischi di macchina virtuale dopo un failover. Per assicurare la correttezza dei backup, è necessario usare un prodotto di backup come Data Protection Manager per eseguire il backup e il ripristino dei dati dell'applicazione.

È possibile eseguire il ripristino dei Database SQL di Azure grazie alla funzionalità di ripristino temporizzato disponibile per i livelli Basic, Standard o Premium. Per altre informazioni, vedere Backup e ripristino del database SQL di Azure.

Oltre a usare il punto di ripristino temporizzato, è possibile esportare manualmente il database in un BLOB di archiviazione di Azure tramite il servizio di importazione ed esportazione del Database SQL di Azure di Azure. Ciò può essere implementato in tre modi:

  • Esportare in un BLOB usando un account di archiviazione in un data center diverso

  • Esportare in un BLOB usando un account di archiviazione nello stesso data center (usare la replica geografica di Archiviazione di Azure per il data center separato).

  • Importare nell'istanza di SQL Server locale.

Per informazioni dettagliate sull'implementazione, vedere l'articolo Continuità aziendale nel database SQL di Azure in MSDN.

Sono disponibili due opzioni consigliate per il recupero di un database SQL Server in esecuzione in una piattaforma IaaS in un data center alternativo di Azure: i gruppi di disponibilità AlwaysOn tra aree o il backup e il ripristino tramite i BLOB di archiviazione.

È anche possibile usare il mirroring del database, ma questa funzionalità verrà rimossa in una versione futura di SQL Server. Quando si usa il mirroring di database per il ripristino di emergenza, è necessario che il server principale e il server mirror siano in esecuzione in data center di Azure diversi. Pertanto è necessario distribuire usando i certificati del server, poiché un dominio Active Directory non può estendersi su più data center di Azure senza indirizzare il traffico tramite una rete locale. Nel seguente diagramma viene illustrata questa impostazione.

Mirroring del database (DR) in Microsoft Azure

Il diagramma seguente illustra il backup e il ripristino standard con i BLOB di archiviazione di Azure.

Backup nel BLOB in Microsoft Azure

Per altre informazioni, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure.

Quando si tenta di eseguire il servizio cloud in più aree di Azure, è necessario considerare le implicazioni per ognuna delle dipendenze. Nelle sezioni seguenti, per le informazioni aggiuntive specifiche del servizio si presuppone che sia necessario usare lo stesso servizio Azure in un data center alternativo di Azure. Sono pertanto necessarie attività di replica dei dati e di configurazione.

Si noti che in alcuni casi questi passaggi possono facilitare l'attenuazione con un'interruzione specifica del servizio a posto di un evento di un intero data center. Dalla prospettiva dell'applicazione, un'interruzione specifica del servizio potrebbe essere semplicemente una limitazione che richiederebbe la migrazione temporanea del servizio in un'area alternativa di Azure.

Il servizio Access Control (ACS) usa un nome di spazio dei nomi univoco che non si estende in più aree di Azure. ACS 2.0 esegue il backup di tutti gli spazi dei nomi una volta al giorno e li archivia in un luogo esterno sicuro. In caso di emergenza, il personale addetto al funzionamento di ACS può tentare di recuperare le sottoscrizioni dei clienti in una regione remota di Azure utilizzando il backup più recente. A causa della frequenza dei backup, è possibile che si verifichi una perdita di dati fino a 24 ore. Non è previsto alcun contratto di servizio per il failover di area e il tempo di recupero può essere di alcuni giorni a seconda dello scenario.

Per usare ACS in un'area alternativa, i clienti devono configurare nell'area uno spazio dei nomi ACS. I clienti di ACS 2.0 interessati alla potenziale perdita di dati possono esaminare il servizio di gestione ACS 2.0. Questa interfaccia consente agli amministratori di gestire gli spazi dei nomi e importare ed estrarre tutti i dati rilevanti. Usando questa interfaccia, i clienti di ACS hanno la possibilità di sviluppare soluzioni di backup e ripristino personalizzate per un livello più elevato di coerenza dei dati rispetto a quello attualmente offerto da ACS. Per altre considerazioni sulla disponibilità, vedere Servizio Access Control (disponibilità).

Analogamente al servizio Access Control, Service Bus usa uno spazio dei nomi univoco che non si estende in più aree di Azure. Pertanto il primo requisito consiste nel configurare gli spazi dei nomi necessari di Service Bus nell'area alternativa. Tuttavia, è opportuno tenere presenti alcune considerazioni circa la durabilità dei messaggi in coda. Sono disponibili diverse strategie per la replica dei messaggi tra le aree di Azure. Per informazioni dettagliate sulle strategie di replica e su altre strategie di ripristino di emergenza, vedere Protezione delle applicazioni di Service Bus da interruzioni e situazioni di emergenza di Service Bus. Per altre considerazioni sulla disponibilità, vedere Service Bus (disponibilità).

Per eseguire la migrazione di un sito Web di Azure in un'area secondaria di Azure, è necessario eseguire il backup del sito Web disponibile per la pubblicazione. Se l'interruzione non riguarda l'intero data center di Azure, è possibile usare FTP per scaricare un backup recente del contenuto del sito. Creare un nuovo sito Web nell'area alternativa, a meno che non sia già stato fatto in precedenza per riservare la capacità. Pubblicare il sito nella nuova area e apportare le modifiche di configurazione necessarie. Queste modifiche possono riguardare le stringhe di connessione dei database o altre impostazioni specifiche dell'area. Se necessario, aggiungere il certificato SSL del sito e modificare il record DNS CNAME in modo che il nome di dominio personalizzato punti all'URL del sito Web di Azure ridistribuito.

Nell'area secondaria di Azure, creare un servizio mobile di backup per l'applicazione. Ripristinare il Database SQL di Azure nell'area alternativa. Usare gli strumenti della riga di comando di Azure per spostare il servizio mobile nell'area alternativa. Configurare il servizio per usare il database ripristinato. Per altre informazioni su questo processo, vedere l'articolo relativo al recupero del servizio mobile in caso di emergenza. Per altre considerazioni sulla disponibilità, vedere Servizi mobili (disponibilità).

I dati associati a HDInsight vengono archiviati per impostazione predefinita nel servizio di archiviazione BLOB di Azure. HDInsight richiede che un cluster Hadoop che elabora i processi MapReduce venga collocato nella stessa area dell'account di archiviazione contenente i dati attualmente analizzati. Usando la funzionalità di replica geografica disponibile in Archiviazione di Azure, è possibile accedere ai dati dell'area secondaria in cui è avvenuta la replica quando per un qualsiasi motivo l'area principale non è più disponibile. È possibile creare un nuovo cluster Hadoop nell'area in cui i dati sono stati replicati e continuare l'elaborazione. Per altre considerazioni sulla disponibilità, vedere HDInsight (disponibilità).

Attualmente, il recupero dalla perdita di un'area di Azure richiede più istanze di report SQL in diverse aree di Azure. Queste istanze di Report SQL devono accedere agli stessi dati e tali dati devono disporre di un proprio piano di recupero in caso di emergenza. È inoltre possibile gestire copie di backup esterne del file RDL per ogni report.

Servizi multimediali di Azure ha un approccio di recupero diverso per la codifica e il flusso. In genere, il flusso è più importante nel caso di un'interruzione dell'area. A tale scopo, è necessario disporre di un account dei servizi multimediali in due diverse aree di Azure. Il contenuto codificato deve trovarsi in entrambe le aree. In caso di errore, è possibile reindirizzare il traffico del flusso all'area alternativa. La codifica può essere eseguita in qualsiasi area di Azure. Se la codifica varia in base al tempo, ad esempio durante l'elaborazione di eventi in diretta, è necessario essere in grado di inviare i processi in un data center alternativo durante gli errori.

I file di configurazione forniscono il modo più rapido per configurare una rete virtuale in un'area alternativa di Azure. Dopo la configurazione della rete virtuale nell'area principale di Azure, esportare le impostazioni di rete virtuale per la rete corrente in un file di configurazione di rete. In caso di errore nell'area principale, ripristinare la rete virtuale dal file di configurazione archiviato. Configurare i servizi cloud, le macchine virtuali o le impostazioni locali per usare la nuova rete virtuale.

 

Servizio/Area Elenco di controllo

Calcolo (PaaS)

  • Creare una strategia di ripristino di emergenza per le aree.

  • Comprendere le conseguenze quando si riserva capacità in aree alternative.

  • Usare gli strumenti di instradamento del traffico, ad esempio Gestione traffico di Azure (CTP).

Macchine virtuali (IaaS)

  • Copiare le risorse dischi di macchina virtuale BLOB in un data center alternativo.

  • Eseguire backup regolari del disco di macchina virtuale o del contenuto del disco.

Archiviazione

  • Non disabilitare la replica geografica delle risorse di archiviazione.

  • Comprendere l'area alternativa per la replica geografica in caso di failover.

  • Creare le strategie di backup personalizzate per le strategie di failover controllate dall'utente.

Database SQL (ripristino di emergenza)

  • Usare il ripristino temporizzato del Database SQL di Azure.

  • Esportare Database SQL di Azure nel servizio di archiviazione BLOB.

  • Creare un piano di ripristino di emergenza basato sulle considerazioni di archiviazione precedenti.

SQL Server nelle macchine virtuali (ripristino di emergenza)

  • Usare il mirroring del database o i gruppi di disponibilità AlwaysOn tra aree.

  • In alternativa usare il backup e il ripristino nel servizio di archiviazione BLOB.

Servizio Access Control (ripristino di emergenza)

  • Configurare uno spazio dei nomi di ACS in un'area alternativa.

  • Usare il servizio di gestione ACS 2.0 per creare soluzioni di backup personalizzate.

Service Bus (ripristino di emergenza)

  • Configurare uno spazio di Service Bus in un'area alternativa.

  • Considerare le strategie di replica personalizzate per i messaggi tra le aree.

Siti Web (ripristino di emergenza)

  • Gestire i backup dei siti Web all'esterno dell'area principale.

  • Se l'interruzione è parziale, tentare di recuperare il sito corrente con FTP.

  • Pianificare la distribuzione del sito Web o in un sito Web nuovo o esistente in un'area alternativa.

  • Pianificare le modifiche di configurazione per i record DNS CNAME e dell'applicazione.

Servizi mobili (ripristino di emergenza)

  • Creare un servizio mobile di backup in un'area alternativa.

  • Gestire i backup del Database SQL di Azure associato da ripristinare durante il failover.

  • Usare gli strumenti della riga di comando di Azure per spostare il servizio mobile.

HDInsight (ripristino di emergenza)

  • Creare un nuovo cluster Hadoop nell'area con i dati replicati.

Report SQL (ripristino di emergenza)

  • Gestire un'istanza di Report SQL alternativa in un'area diversa.

  • Gestire un piano separato per replicare la destinazione nell'area.

Servizi multimediali (ripristino di emergenza)

  • Creare un account di servizi multimediali in un'area alternativa.

  • Codificare lo stesso contenuto in entrambe le aree per supportare il failover del flusso.

  • Inviare i processi di codifica a un'area alternativa in caso di interruzione.

Rete virtuale (ripristino di emergenza)

  • Usare le impostazioni di rete virtuale esportate per ricrearle in un'altra area.

Azure offre un set completo di servizi per abilitare l'estensione di un data center locale a Azure per scopi di ripristino di emergenza e disponibilità elevata:

  • Rete: con la rete privata virtuale si estende in modo sicuro la rete locale al cloud.

  • Calcolo: i clienti che usano Hyper-V in locale possono "sollevare e spostare" le macchine virtuali esistenti in Azure

  • Archiviazione: StorSimple estende il file system al servizio di archiviazione di Azure. Il servizio di backup di Azure fornisce il backup dei file e dei Database SQL di Azure ad Archiviazione di Azure

  • Replica database: con i gruppi di disponibilità di SQL 2014 è possibile implementare la disponibilità elevata e il ripristino di emergenza per i dati locali

La rete virtuale di Azure consente di creare una sezione logicamente in isolamento in Azure e per connetterla in modo sicuro al data center locale o a un singolo computer client usando una connessione IPsec. La rete virtuale consente di sfruttare l'infrastruttura su richiesta scalabile di Azure offrendo connettività ai dati e alle applicazioni locali, inclusi i sistemi eseguiti su Windows Server, mainframe e UNIX. Per altre informazioni, fare clic qui.

i clienti che usano Hyper-V in locale possono "sollevare e spostare" le macchine virtuali esistenti in Azure e i provider del servizio in esecuzione in Azure 2012, senza apportare alcuna modifica alla macchina virtuale o conversione ai formati di macchina virtuale. Per altre informazioni, vedere Gestisci dischi e immagini.

Sono disponibili diverse opzioni per l'uso di Azure come sito di backup per i dati locali.

StorSimple integra in modo sicuro e trasparente l'archiviazione cloud per le applicazioni locali e offre un singolo strumento che fornisce l'archiviazione cloud e locale a livelli a elevate prestazioni, l'archiviazione in diretta, la protezione dei dati basata sul cloud e il ripristino di emergenza. Per altre informazioni, vedere il documento relativo a StorSimple - Archiviazione integrata e cloud: indicazioni e motivazioni.

I servizi di backup di Azure consentono di eseguire i backup del cloud tramite i familiari strumenti di backup di Windows Server 2012, Windows Server 2012 Essentials e System Center 2012 Data Protection Manager. Questi strumenti offrono un flusso di lavoro per la gestione dei backup indipendente dal percorso di archiviazione dei backup, un disco locale o Archiviazione di Azure. Dopo aver eseguito il backup dei dati nel cloud, gli utenti autorizzati possono facilmente ripristinarlo in qualsiasi server.

Con i backup incrementali, solo le modifiche dei file vengono trasferite nel cloud. In tal modo si usa lo spazio di archiviazione in modo efficiente, si riduce l'uso della larghezza di banda e si offre un recupero temporizzato di più versioni di dati. È inoltre possibile scegliere di usare funzionalità aggiuntive, quali i criteri di memorizzazione dei dati, la compressione dei dati e la limitazione delle richieste di trasferimento dei dati. L'utilizzo di Azure come percorso di backup è un evidente vantaggio in quanto i backup vengono automaticamente all'esterno. In tal modo si eliminano i requisiti per proteggere i supporti di backup locali. Per altre informazioni, vedere Panoramica di Backup di Azure e Uso di DPM con Backup di Azure.

È possibile disporre di una soluzione di ripristino di emergenza per i database SQL Server in un ambiente IT ibrido tramite gruppi di disponibilità AlwaysOn, mirroring del database, log shipping e backup e ripristino con l'archiviazione BLOB di Azure. Tutte queste soluzioni usano SQL Server in esecuzione in Macchine virtuali di Azure.

I gruppi di disponibilità AlwaysOn possono essere usati in un ambiente ibrido IT in cui le repliche dei database sono presenti in locale e nel cloud. Ciò viene illustrato nel diagramma seguente preso dall'articolo tecnico Disponibilità elevata e ripristino di emergenza per SQL Server in Macchine virtuali di Azure.

Gruppi di disponibilità AlwaysOn in ambiente IT ibrido

Il mirroring del database può inoltre estendere i server locali e il cloud in una configurazione basata sui certificati. Nel seguente diagramma viene illustrato questo concetto.

Mirroring del database in ambiente IT ibrido

Il log shipping può essere usato per sincronizzare un database locale con un database SQL Server in una macchina virtuale di Azure.

Log shipping in ambiente IT ibrido

Infine, è possibile eseguire il backup di un database locale direttamente nel servizio di archiviazione BLOB di Azure.

Backup nel blog in ambiente IT ibrido

Per altre informazioni, vedere Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure e Backup e ripristino per SQL Server in Macchine virtuali di Azure.

 

Servizio/Area Elenco di controllo

Rete

  • Usare la rete virtuale per la connessione sicura dello scenario locale al cloud.

Calcolo

  • Rilocare le macchine virtuali tra Hyper-V e Azure.

Archiviazione

  • Impiegare i servizi StorSimple per usare l'archiviazione cloud.

  • Usare i servizi di backup di Azure.

Database

  • Considerare l'uso di SQL Server nelle macchine virtuali di Azure come backup.

  • Impostare i gruppi di disponibilità AlwaysOn.

  • Configurare il mirroring del database basato sui certificati.

  • Usare il log shipping.

  • Eseguire il backup del database locale nel servizio di archiviazione BLOB di Azure.

Questo scenario riguarda il recupero dei dati danneggiati o eliminati per errore a causa di errori dell'applicazione o dell'operatore.

Si noti che anche se tramite Archiviazione di Azure viene fornita la resilienza dei dati attraverso repliche automatizzate, non è possibile evitare il danneggiamento dei dati da parte del codice dell'applicazione (o di sviluppatori/utenti) a causa di eliminazioni e aggiornamenti accidentali o indesiderati e così via. Per mantenere la conformità dei dati in caso di errore dell'applicazione o da parte dell'utente sono richieste tecniche più avanzate, ad esempio la copia dei dati in un percorso di archiviazione secondario con un log di controllo. Gli sviluppatori possono usare la funzionalità snapshot dei BLOB che consente di creare snapshot di sola lettura di momenti specifici del contenuto del BLOB. Può essere usata come base per una soluzione di conformità per i BLOB.

Sebbene BLOB e tabelle siano altamente durevoli, rappresentano sempre lo stato corrente dei dati. Il recupero da una modifica o da un'eliminazione di dati indesiderata può richiedere il ripristino dei dati a uno stato precedente. A questo scopo, è possibile sfruttare le funzionalità disponibili in Azure per l'archiviazione e il mantenimento di copie temporizzate.

Per i BLOB di Azure è possibile eseguire backup temporizzati tramite la funzionalità per la creazione di snapshot di BLOB. Per ogni snapshot viene addebitato solo lo spazio richiesto per l'archiviazione delle differenze all'interno del BLOB dall'ultimo stato dello snapshot. Gli snapshot dipendono dall'esistenza del BLOB originale su cui si basano, pertanto è consigliabile un'operazione di copia in un altro BLOB o in un altro account di archiviazione per assicurarsi che i dati di backup siano correttamente protetti da eliminazioni accidentali. Per le tabelle di Azure è possibile eseguire copie temporizzate in una tabella diversa o in BLOB di Azure. Informazioni aggiuntive più dettagliate ed esempi relativi all'esecuzione di backup a livello di applicazione di tabelle e BLOB sono disponibili qui:

Sono disponibili diverse opzioni di continuità aziendale (backup, ripristino) per Database SQL di Azure. I database possono essere copiati tramite la funzionalità di copia del database o il servizio di importazione/esportazione dell'applicazione livello dati. A differenza di un file bacpac generato dal servizio di importazione/esportazione, la funzionalità di copia del database fornisce risultati coerenti dal punto di vista transazionale. Entrambe le opzioni vengono eseguite come servizi basati su coda nel data center e non forniscono attualmente un contratto di servizio sul tempo necessario per il completamento.

noteNota
Si noti che la copia del database e il servizio di importazione/esportazione comportano un livello di carico significativo nel database di origine e possono attivare eventi di contesa o di limitazione delle richieste, descritti nella sezione "Risorse condivise e limitazione delle richieste" riportata di seguito.

I backup temporizzati per Database SQL di Microsoft Azure vengono creati tramite il comando descritto in Copia di database nel database SQL di Azure. È possibile usare questo comando per creare una copia coerente dal punto di vista transazionale di un database nello stesso server di database logico o in un server diverso. In entrambi i casi, la copia del database è completamente funzionale e indipendente dal database di origine. Ogni copia creata rappresenta un'opzione di recupero temporizzato. È possibile recuperare completamente lo stato del database rinominando il nuovo database con il nome del database di origine. In alternativa, è possibile recuperare un subset specifico di dati dal nuovo database usando query Transact-SQL. Per altre informazioni dettagliate su Database SQL, vedere Continuità aziendale nel database SQL di Azure.

Per SQL Server su IaaS sono disponibili due opzioni: i backup tradizionali e il log shipping. I backup tradizionali consentono di ripristinare a un momento specifico, ma il processa di recupero è lento. Il ripristino dei backup tradizionali richiede inizialmente l'esecuzione di un backup completo e quindi l'applicazione di tutti i backup eseguiti successivamente. La seconda opzione consiste nel configurare una sessione di log shipping per ritardare il ripristino dei backup del log, ad esempio di due ore. Ciò consente di recuperare gli errori di una finestra apportati nel server primario.

Alcuni servizi della piattaforma Azure archiviano le informazioni in un account di archiviazione controllato dall'utente o in Database SQL di Azure. Se l'account o la risorsa di archiviazione viene eliminata oppure danneggiata, si potrebbero verificare errori gravi relativi al servizio. In questi casi, è importante mantenere i backup che consentono di ricreare tali risorse se vengono eliminate o danneggiate.

Per i siti Web di Azure e i servizi mobili di Azure, è necessario eseguire il backup e gestire i database associati. Per le macchine virtuali e il servizio multimediale di Azure, è necessario gestire l'account associato di Archiviazione di Azure e tutte le risorse dell'account. Ad esempio, per le macchine virtuali è necessario eseguire il backup e gestire i dischi di macchina virtuale nel servizio di archiviazione BLOB di Azure.

 

Servizio/Area Elenco di controllo

Archiviazione

  • Eseguire regolarmente il backup delle risorse di archiviazione critiche.

  • Usare la funzionalità snapshot per i BLOB.

Database

  • Creare backup temporizzati tramite il comando di copia del database.

SQL Server per il backup delle macchine virtuali (IaaS)

  • Usare le tecniche tradizionali di backup e ripristino.

  • Creare una sessione di log shipping ritardata

Siti Web

  • Eseguire il backup e gestire il database associato se presente.

Servizi mobili

  • Eseguire il backup e gestire il database associato.

Servizi multimediali

  • Eseguire il backup e gestire le risorse di archiviazione associate.

Macchine virtuali

  • Eseguire il backup e gestire i dischi di macchina virtuale nel servizio di archiviazione BLOB.

Operatore alternativo: informazioni aggiuntive per architetture cloud resilienti: informazioni generali per la compilazione di architetture cloud resilienti, nonché per l'implementazione di queste architetture sia con tecnologie Microsoft sia per scenari specifici.

Ripristino di emergenza e disponibilità elevata per applicazioni Azure: panoramica dettagliata della disponibilità e del ripristino di emergenza. Viene illustrata la replica manuale per i dati di riferimento e transazionali. Nelle sezioni finali vengono riportati i riepiloghi dei diversi tipi di topologie di ripristino di emergenza che estendono i data center di Azure per il livello di disponibilità più elevato.

Continuità aziendale del database SQL di Azure: illustra esclusivamente le tecniche per la disponibilità del Database SQL di Azure di Azure, che consistono in sostanza nelle strategie di backup e ripristino. Se si usa Database SQL di Azure nel servizio cloud, è necessario rivedere questo documento e le relative risorse correlate.

Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure: descrive le opzioni di disponibilità aperte quando si usa IaaS per ospitare i servizi di database. Vengono illustrati i gruppi di disponibilità AlwaysOn, il mirroring di database, il log shipping e il backup e il ripristino. Si noti che sono disponibili anche diverse esercitazioni nella sezione che illustrano come usare queste tecniche.

Procedure consigliate per la progettazione di servizi su larga scala nei servizi cloud di Azure: illustra la procedura per lo sviluppo di architetture cloud altamente scalabili. Molte delle tecniche che si impiegano per migliorare la scalabilità migliorano anche la disponibilità. Inoltre, se la scalabilità dell'applicazione non è consentita nei carichi aumentati, diventa un problema di disponibilità.

Backup e ripristino per SQL Server in Macchine virtuali di Azure

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2015 Microsoft