Perché la ridondanza è una scelta architetturale

Ogni storage account conserva più copie dei dati per proteggerli da guasti hardware, di zona o di regione. La domanda d’esame non è “cos’è LRS”, ma “in questo scenario, quale opzione garantisce il livello di durabilità e disponibilità richiesto al costo più basso”. La ridondanza si sceglie lungo due assi: replica locale (in un solo datacenter vs. distribuita su più availability zone) e replica geografica (copia asincrona in una paired region secondaria).

Le cinque opzioni chiave

  • LRS (Locally Redundant Storage): tre copie sincrone in un singolo datacenter. Durabilità 11 nine, ma nessuna protezione se l’intero datacenter o la zona va giù. È l’opzione più economica: adatta a dati ricostruibili, staging, o quando esistono vincoli di residenza che vietano la replica geografica.
  • ZRS (Zone-Redundant Storage): tre copie sincrone distribuite su tre availability zone della stessa regione. Sopravvive alla perdita di una zona senza downtime né perdita dati. È la scelta per high availability intra-regione (es. workload sempre attivi in una regione con zone).
  • GRS (Geo-Redundant Storage): LRS nella regione primaria più replica asincrona in tre copie LRS nella regione secondaria accoppiata. Protegge da un disastro regionale, ma la secondaria è “fredda”: non accessibile finché non avviene un failover.
  • RA-GRS (Read-Access GRS): identico a GRS, ma abilita read access all’endpoint secondario (<account>-secondary) senza failover. Utile per offloading di letture read-only o per continuità di lettura durante un’interruzione della primaria.
  • GZRS (Geo-Zone-Redundant Storage): combina ZRS in primaria (tre zone, sincrono) con replica asincrona LRS in secondaria. È il massimo: resilienza sia di zona sia di regione. La variante RA-GZRS aggiunge la lettura sulla secondaria.

Failover account-level e RPO

Con GRS/GZRS la replica verso la secondaria è asincrona: esiste un ritardo, misurato dalla proprietà Last Sync Time, che rappresenta l’RPO (dati non ancora replicati che potrebbero andare persi in un failover non pianificato). Il customer-managed failover promuove la secondaria a primaria; dopo il failover l’account degrada automaticamente a LRS, quindi va riconfigurata la geo-ridondanza (con nuovo costo di ri-replica). Va valutato con attenzione perché ha implicazioni su costo e consistency.

Account kind e performance tier

  • StorageV2 (general-purpose v2) è l’account kind standard e raccomandato: supporta blob, file, queue, table, tiering Hot/Cool/Cold/Archive e tutte le opzioni di ridondanza.
  • Premium usa dischi SSD/NVMe per bassa latenza e IOPS elevati, ma è disponibile solo in varianti specializzate (Block blob, File share, Page blob) e supporta solo LRS e ZRS — mai geo-ridondanza.
  • Il performance tier si sceglie a monte: Standard (HDD, costo/GB basso, throughput moderato) per la maggior parte dei workload; Premium quando servono latenza in singoli millisecondi e transazioni intensive (es. file share per VM, indici, database file). Il tier non è convertibile dopo la creazione: va deciso in fase di provisioning.

Trappole tipiche d’esame

  • Scenario: serve resilienza a un disastro regionale e un endpoint da cui leggere i dati anche prima del failover → RA-GRS (o RA-GZRS). GRS “semplice” protegge i dati ma la secondaria non è leggibile senza read access.
  • Scenario: workload mission-critical in una regione con zone, che deve sopravvivere alla perdita di una zona senza downtime, ma i dati non possono lasciare la regione → ZRS, non GRS (la geo-replica violerebbe la residenza).
  • Scenario: account Premium e si chiede GRS → impossibile. Premium supporta solo LRS o ZRS; per la geo-ridondanza serve Standard StorageV2.
  • Scenario: dopo un customer-managed failover si assume che l’account resti geo-ridondante → falso: degrada a LRS e la geo-ridondanza va riconfigurata, con costi aggiuntivi.
  • Scenario: si punta a “zero perdita dati” con GRS in un failover non pianificato → errato: la replica è asincrona, quindi c’è un RPO > 0; verificare Last Sync Time prima di decidere il failover.