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à sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.
Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone 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 inattività della zona
Quando si distribuisce una SAN elastica, se si seleziona archiviazione con ridondanza della rete per l'opzione di ridondanza della rete SAN, il failover di zona è supportato dalla piattaforma. Se si usa un endpoint privato per connettersi alla rete SAN elastica, questo failover viene eseguito senza intervento manuale. Una SAN elastica dell'archiviazione con ridondanza della zona usando endpoint privati ed è progettata per la riparazione automatica e il ribilanciamento per sfruttare automaticamente le zone integre. La disponibilità e la riduzione delle prestazioni possono verificarsi per alcuni minuti dopo un failover, fino a quando la san non viene ribilanciata.
Se ci si connette usando gli endpoint del servizio di archiviazione, il failover di zona è supportato ma potrebbe richiedere un intervento manuale. Una san elastica dell'archiviazione con ridondanza della zona con endpoint di servizio di archiviazione non passerà automaticamente a una zona integra. Potrebbe essere necessario riavviare l'iniziatore iSCSI per avviare un failover in una zona diversa e integra.
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
La distribuzione di una san elastica dell'archiviazione con ridondanza della zona offre maggiore affidabilità rispetto a una san elastica con ridondanza locale, ma aggiunge una latenza di scrittura maggiore. Eseguire il benchmark della san elastica e simulare il carico di lavoro dell'applicazione per confrontare la latenza tra archiviazione con ridondanza locale e archiviazione con ridondanza della zona, per verificare se influisce sul carico di lavoro.
Migrazione della zona di disponibilità
Per eseguire la migrazione di una san elastica nell'archiviazione con ridondanza locale a archiviazione con ridondanza della zona, creare snapshot delle san elastiche, esportarli in snapshot del disco gestito, distribuire una SAN elastica nell'archiviazione con ridondanza della zona e quindi creare volumi nella rete SAN in archiviazione 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).
Ripristino di emergenza e continuità aziendale
Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili 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 (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.
Ripristino di emergenza in una singola area e in più aree
Per la san elastica, 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 per archiviare i dati 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. Convalidare in modo preliminare qualsiasi servizio distribuito funziona con ELASTIC SAN. Per assicurarsi che il ripristino sia proattivo, pre-distribuire i database secondari per assicurarsi che non siano presenti problemi di capacità se gli ambienti sono interessati.