Affidabilità nella san elastica
Questo articolo descrive il supporto per l'affidabilità in SAN elastico di Azure e illustra sia la resilienza a livello di area con le zone di disponibilità che il ripristino di emergenza e la continuità aziendale.
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.
Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.
I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.
San elastico di Azure supporta la distribuzione della zona di disponibilità con l'archiviazione con ridondanza locale e la distribuzione a livello di area con archiviazione con ridondanza della zona.
Prerequisiti
L'archiviazione con ridondanza locale e san elastica dell'archiviazione con ridondanza della zona sono attualmente disponibili solo in un subset di aree. Per un elenco delle aree, vedere Scale targets for Elastic SAN (Destinazioni di scalabilità per SAN elastico).
Creare una risorsa usando le zone di disponibilità
Per creare una san elastica con una zona di disponibilità abilitata, vedere Distribuire una SAN elastica.
Esperienza di riduzione della zona
Quando si distribuisce una san elastica, se si seleziona archiviazione con ridondanza della rete san per l'opzione di ridondanza della rete SAN, il failover di zona è supportato dalla piattaforma senza intervento manuale. Una SAN elastica che usa l'archiviazione con ridondanza della zona è progettata per auto-guarire e ribilanciarsi per sfruttare automaticamente le zone sane.
Se è stata distribuita una san elastica con ridondanza locale, potrebbe essere necessario distribuire una nuova san usando gli snapshot esportati in dischi gestiti.
Progettazione a bassa latenza
Le differenze di latenza tra una san elastica in archiviazione con ridondanza locale e una san elastica in ZRS non sono particolarmente elevate. Tuttavia, per i carichi di lavoro sensibili ai picchi di latenza, prendere in considerazione un'archiviazione SAN elastica in archiviazione con ridondanza locale perché offre la latenza più bassa.
Ridistribuzione e migrazione della zona di disponibilità
Per eseguire la migrazione di una san elastica nelle archiviazioni con ridondanza della zona, è necessario creare uno snapshot dei volumi san elastici, esportarli in snapshot del disco gestito, distribuire una SAN elastica nell'archiviazione con ridondanza della zona e quindi creare volumi nella rete SAN con ridondanza della zona usando gli snapshot del disco. Per informazioni su come usare gli snapshot (anteprima), vedere Snapshot dei volumi SAN elastici di Azure (anteprima).
Continuità aziendale e ripristino di emergenza
Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.
Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.
Ripristino di emergenza in una singola area e in più aree
Per la san elastica di Azure, si è responsabili dell'esperienza di ripristino di emergenza. È possibile creare snapshot dei volumi ed esportarli in snapshot del disco gestito. È quindi possibile copiare uno snapshot incrementale in una nuova area in cui archiviare i dati si trova in un'area diversa dall'area in cui si trova la rete SAN elastica. È consigliabile esportare in aree geograficamente distanti dall'area primaria per ridurre la possibilità che più aree siano interessate a causa di un'emergenza.
Rilevamento, notifica e gestione di interruzioni
È possibile trovare le dichiarazioni di interruzione in Integrità dei servizi - Microsoft Azure.
Resilienza della capacità e del ripristino di emergenza proattivo
Microsoft e i suoi clienti operano con il modello di responsabilità condivisa. Responsabilità condivisa significa che per il ripristino di emergenza abilitato per il cliente (servizi responsabili del cliente), è necessario rivolgersi al ripristino di emergenza per qualsiasi servizio distribuito e controllato. È consigliabile prevalidare qualsiasi servizio distribuito funzionerà con elastico SAN. Per garantire che il ripristino sia proattivo, è consigliabile pre-distribuire sempre i database secondari perché non esiste alcuna garanzia di capacità al momento dell'impatto per coloro che non sono stati preallocati.