Affidabilità in SAN di Elastic in Azure

SAN di Elastic in Azure è un servizio san (Storage Area Network) nativo del cloud che offre una soluzione di archiviazione scalabile, conveniente, a prestazioni elevate e completa per una gamma di opzioni di calcolo. La san elastica consente di creare e gestire volumi, ovvero dischi virtuali che è possibile connettere alle macchine virtuali, ai contenitori o ad altri servizi Azure tramite il protocollo iSCSI.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere SAN di Elastic in Azure resiliente a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, errori della zona di disponibilità e errori a livello di area. Descrive anche le opzioni di backup e ripristino ed evidenzia le informazioni chiave sul contratto di servizio SAN di Elastic in Azure.

Raccomandazioni per la distribuzione di produzione per l'affidabilità

Per i carichi di lavoro di produzione, è consigliabile:

Panoramica dell'architettura di affidabilità

La rete SAN elastica ha una gerarchia di risorse a tre livelli:

• SAN elastico: risorsa di primo livello in cui è possibile configurare la ridondanza, allocare la capacità di archiviazione e impostare i limiti di prestazioni. Il numero di unità di base allocate alla SAN Elastica determina il totale di IOPS e la velocità effettiva disponibile in tutta la SAN.
• Gruppi di volumi: costrutti di gestione usati per gestire i volumi su larga scala. Le impostazioni di accesso alla rete, ad esempio endpoint privati o endpoint di servizio, vengono configurate a livello di gruppo di volumi e ereditate da tutti i volumi del gruppo.
• Volumi: volumi di archiviazione singoli partizionati dalla capacità totale della SAN. I volumi sono connessi alle risorse di calcolo tramite il protocollo iSCSI.

Per ulteriori dettagli sulle risorse che distribuisci, consulta Risorse SAN elastici.

Internamente, Elastic SAN archivia i dati all'interno dei cluster di archiviazione. Quando si configura la rete SAN elastica per l'uso dell'archiviazione con ridondanza locale, i dati vengono replicati tre volte all'interno di un singolo cluster di archiviazione in un data center. È possibile configurare l'archiviazione con ridondanza della zona per archiviare copie dei dati in tre zone di disponibilità. Per altre informazioni, vedere Resilienza agli errori della zona di disponibilità.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Se la connessione iSCSI a un volume SAN elastico viene interrotta, l'iniziatore iSCSI nel client tenta automaticamente di riconnettersi. È possibile che si verifichi una breve pausa nelle operazioni di I/O durante la riconnessione. Configurare l'iniziatore iSCSI con impostazioni appropriate di ripetizione e timeout per gestire le interruzioni temporanee. Per indicazioni dettagliate sulle impostazioni iSCSI e MPIO, consultare Optimize the performance of your Elastic SAN.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

SAN di Elastic in Azure può essere configurato per l'uso dell'archiviazione con ridondanza della zona( ZRS), il che significa che i dati vengono replicati in modo sincrono in tre zone di disponibilità nell'area. La ridondanza della zona consente di ottenere resilienza e affidabilità per i carichi di lavoro di produzione.

L'approccio alla connettività influisce sulla capacità del carico di lavoro di eseguire il failover in modo trasparente durante un guasto della zona. Consigliamo di usare endpoint privati per connettere i tuoi volumi. Gli endpoint privati supportano il failover automatico. Se si usano endpoint di servizio, il failover potrebbe richiedere un intervento manuale. Per altre informazioni sugli approcci alla connettività, vedere Informazioni sulle configurazioni di rete per la san elastica.

L'uso dell'archiviazione con ridondanza locale lascia la SAN elastica non protetta dai guasti della zona di disponibilità. LRS rende il SAN elastico non zonale archiviando i dati in una singola zona di disponibilità anziché distribuirli tra più zone con archiviazione con ridondanza di zona (ZRS).

Requisiti

Supporto per l'area: Le risorse SAN elastiche con ridondanza della zona possono essere distribuite in un subset di aree. Per un elenco delle aree, vedere Obiettivi di scalabilità per SAN di Elastic.

Cost

Quando si crea una SAN elastica con ZRS (Zona Redundancy Storage), il costo è superiore rispetto a LRS (Local Redundancy Storage). Per altre informazioni sui prezzi, vedere SAN di Elastic in Azure prezzi.

Configurare il supporto delle zone di disponibilità

• Creare una nuova SAN elastica con ZRS: Quando si crea una SAN elastica e si seleziona ZRS come opzione di ridondanza, la SAN elastica è automaticamente a ridondanza di zona. Non è possibile modificare l'opzione di ridondanza dopo la creazione della SAN elastica. Per ulteriori informazioni sulla creazione di una nuova risorsa SAN elastica, vedere Implementare una SAN elastica.

• Abilitare la ridondanza della zona su un LRS Elastic SAN esistente: Non è possibile convertire un LRS Elastic SAN in ZRS. Per eseguire la migrazione, creare uno snapshot dei volumi SAN elastici, esportarli come snapshot del disco gestito, distribuire una nuova SAN Elastica su ZRS e quindi creare volumi sulla nuova SAN Elastica utilizzando tali snapshot del disco. Per ulteriori informazioni, vedere i volumi di Snapshot SAN di Elastic in Azure.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando si configura una SAN elastica per la ridondanza delle zone, quando tutte le zone sono operative.

• Operazione tra zone: Quando ci si connette a un volume SAN elastico, la connessione iSCSI instrada a un cluster in una delle zone di disponibilità. La piattaforma instrada automaticamente il traffico tra le zone.

• Replica dei dati tra zone: Quando un client scrive dati in un volume SAN elastico, tali dati vengono scritti in modo sincrono nei cluster all'interno di tre zone di disponibilità prima che l'operazione di scrittura venga riconosciuta. La replica sincrona garantisce un elevato livello di coerenza dei dati e garantisce che non si verifichi alcuna perdita di dati durante un errore di zona.

  La distribuzione di una SAN di Elastic ZRS offre maggiore affidabilità rispetto a una SAN di Elastic LRS, ma aggiunge una latenza di scrittura maggiore. Eseguire il benchmark della SAN di Elastic 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.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando si configura una SAN Elastica per la ridondanza della Zona, e si verifica un'interruzione in una delle Zone.

• Rilevamento e risposta: La piattaforma SAN elastica rileva eventuali errori in una zona di disponibilità. Non è necessario eseguire alcuna operazione per avviare un failover di zona per le reti SAN elastiche ZRS.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Quando una zona di disponibilità non è più disponibile, il servizio può terminare le operazioni di I/O in corso che si connettono alle repliche nella zona interessata ed è necessario ripetere tali operazioni. Se si usano endpoint privati, il servizio esegue automaticamente il failover. Se si usano endpoint di servizio, potrebbe essere necessario riavviare l'iniziatore iSCSI per eseguire il failover in una zona integra.

• Perdita di dati prevista: La san elastica impedisce la perdita di dati durante un errore di zona replicando in modo sincrono i dati in tre zone di disponibilità.

• Tempo di inattività previsto: Quando si usano endpoint privati, il failover della zona viene eseguito automaticamente. È possibile che si verifichi una riduzione della disponibilità e delle prestazioni per alcuni minuti dopo un failover mentre la san si ribilancia.

  Quando si usano gli endpoint di servizio, Elastic SAN non passa automaticamente a una zona operativa. Potrebbe essere necessario riavviare l'iniziatore iSCSI per avviare un failover in una zona diversa e integra.

• Reindirizzamento del traffico: Quando una zona non è disponibile, la piattaforma SAN elastica rileva la perdita della zona e instrada il traffico alle zone integre rimanenti.

  Per garantire il failover automatico delle zone senza intervento manuale, utilizzare gli endpoint privati per connettersi all'Elastic SAN. Quando si utilizzano gli endpoint di servizio anziché quelli privati, potrebbe essere necessario riavviare manualmente l'iniziatore iSCSI per iniziare un failover verso una zona funzionante.

Ripristino della zona

Quando la zona di disponibilità viene ripristinata, la piattaforma SAN elastica ripristina automaticamente le normali operazioni e riprende la replica in tre zone. Non è necessario eseguire alcuna azione.

Verifica dei guasti di zona

La piattaforma SAN di Elastic in Azure gestisce il routing del traffico, il failover e il ripristino della zona per le risorse zonali ridondanti. Poiché questa funzionalità è completamente gestita, non è necessario convalidare i processi di errore della zona di disponibilità.

Resilienza agli errori a livello di area

SAN di Elastic in Azure è un servizio a singola area. Se l'area non è più disponibile, anche la risorsa SAN elastica non è disponibile. Non esiste alcuna replica incrociata tra regioni o failover per Elastic SAN. L'utente è responsabile della progettazione della propria soluzione di ripristino di emergenza in più aree se il carico di lavoro richiede resilienza a livello di area.

Soluzioni personalizzate in più aree per la resilienza

Sei responsabile dell'implementazione del ripristino di emergenza multi-regionale per i dati di Elastic SAN. L'approccio consigliato consiste nell'usare gli snapshot del volume:

1. Crea snapshot regolarmente. Usa gli snapshot del volume per acquisire copie istantanee dei tuoi volumi SAN elastici.

   L'obiettivo del punto di ripristino (RPO) dipende dalla frequenza di creazione e copia degli snapshot nell'area secondaria. Più frequentemente si creano snapshot e li si copia, minore è la potenziale perdita di dati durante un'emergenza.

2. Esportare gli snapshot del volume in snapshot dei dischi gestiti.Esportare gli snapshot del volume nei snapshot dei dischi gestiti, che possono essere copiati in altre regioni.

3. Copiare gli snapshot in un'area secondaria.Copiare lo snapshot incrementale in una nuova area geograficamente distante dall'area primaria. In questo modo si riduce il rischio che più aree siano interessate da una singola emergenza.

4. Eseguire il ripristino da snapshot. In uno scenario di ripristino di emergenza, creare nuovi volumi sul SAN Elastico secondario dagli snapshot del disco gestito copiati.

L'obiettivo del tempo di ripristino (RTO) dipende dalle dimensioni dei dati, dal tempo necessario per copiare gli snapshot tra aree e dal tempo necessario per implementare e configurare una nuova Elastic SAN nell'area secondaria. Per ridurre il tempo di ripristino, valutare la possibilità di distribuire una SAN elastica secondaria nell'area di ripristino prima che si verifichi un'emergenza. Ciò consente anche di evitare vincoli di capacità durante un'interruzione.

Backup e ripristino

Per la maggior parte delle soluzioni, non è consigliabile basarsi esclusivamente sui backup. Usare invece le altre funzionalità descritte in questa guida per supportare i requisiti di resilienza. Tuttavia, i backup proteggono da alcuni rischi che altri approcci non comportano. Per altre informazioni, vedere Che cosa sono ridondanza, replica e backup?.

Elastic SAN supporta due tipi di backup:

• SAN di Elastic in Azure backup: Questa funzionalità di Backup di Azure offre una soluzione completamente gestita per pianificare i backup, impostare le sequenze temporali di scadenza per i punti di ripristino e i dati di ripristino in un nuovo volume. Consente di proteggersi dalla perdita di dati da eliminazioni accidentali, ransomware e aggiornamenti dell'applicazione. Per altre informazioni, vedere SAN di Elastic in Azure backup (anteprima).

  Importante

  Poiché questa soluzione è coperta dalle Condizioni supplementari di Microsoft per le anteprime di Azure, usarla per i test e non per l'uso in produzione.

• Istantanee: In alternativa, è possibile creare e gestire istantanee in base ai requisiti di protezione dei dati.

  SAN di Elastic in Azure supporta gli snapshot del volume per la protezione dei dati. Gli snapshot sono copie incrementali istantanee dei tuoi volumi che occupano spazio dalla capacità totale della tua Elastic SAN. Per proteggere i dati, creare regolarmente snapshot. La frequenza dipende da quanti dati puoi permetterti di perdere (il tuo RPO). È possibile creare snapshot manualmente o creare un'automazione personalizzata per crearli in base a una pianificazione.

  Gli snapshot sono archiviati all'interno dello stesso Elastic SAN dei volumi e utilizzano la stessa impostazione di ridondanza. Per proteggersi da guasti a livello regionale, esportare i propri snapshot come snapshot di dischi gestiti e copiarli in una regione diversa. Per altre informazioni, vedere Esportare snapshot del volume e Copiare uno snapshot incrementale in una nuova area.

  È possibile creare nuovo volume SAN elastico da uno snapshot o da uno snapshot di un disco gestito. Per altre informazioni, vedere Creare un volume da uno snapshot.

Resilienza alla manutenzione del servizio

Microsoft applica regolarmente gli aggiornamenti del servizio ed esegue altre operazioni di manutenzione. La piattaforma Azure gestisce automaticamente queste attività, garantendo che la manutenzione sia fluida e trasparente per l'utente. Non è previsto alcun tempo di inattività durante gli eventi di manutenzione, a meno che non ti sia stato comunicato tramite la manutenzione pianificata di integrità dei servizi di Azure.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per ulteriori informazioni, vedere Accordi sul livello di servizio (SLA) per i servizi online.

Contenuti correlati

• Che cos'è SAN di Elastic in Azure?
• Pianificare la distribuzione di una SAN di Elastic
• Affidabilità in Azure