Tradurre il requisito in due numeri

Ogni domanda HA/DR, all’esame come in produzione, si risolve traducendo una frase di business in due numeri. L’RPO (Recovery Point Objective) dice quanti dati si è disposti a perdere: quanto indietro può tornare l’orologio dei dati dopo un guasto. L’RTO (Recovery Time Objective) dice per quanto tempo il servizio può restare indisponibile prima che il danno diventi inaccettabile. Finché il testo parla genericamente di “continuità operativa” non c’è nulla da scegliere: la decisione nasce quando si stabilisce se il requisito tollera la perdita di transazioni recenti e quanto fermo accetta.

Fissati i due numeri, si scorrono le opzioni dalla più stretta alla più lenta e ci si ferma alla prima che li rispetta: andare oltre significa pagare capacità che nessuno ha chiesto.

Dentro la regione: il service tier decide

Nei servizi PaaS la ridondanza locale non si “installa”: è una proprietà del service tier. General Purpose separa compute e storage e in caso di guasto ricrea il nodo di calcolo agganciandolo ai file remoti, quindi il ripristino è rapido ma non istantaneo. Business Critical mantiene un quorum di repliche locali basato sulla tecnologia Always On, offre il ripristino più veloce dentro la regione e mette a disposizione una secondaria leggibile su cui scaricare reportistica e query analitiche.

La configurazione zone-redundant distribuisce quelle repliche fra availability zone diverse della stessa regione: protegge dal guasto di un intero datacenter senza cambiare endpoint, stringa di connessione o logica applicativa. È il gradino giusto quando il requisito parla di guasto localizzato e non di disastro regionale.

Fra regioni: geo-replication, failover group, geo-restore

Quando il requisito nomina esplicitamente la perdita di una regione, la ridondanza locale non basta. Active geo-replication crea copie asincrone di un singolo database in altre regioni; le secondarie sono leggibili e il failover si avvia manualmente, quindi l’applicazione deve sapere a quale endpoint riconnettersi. È la scelta quando servono repliche di lettura geograficamente distribuite e si vuole decidere a mano quando spostare il carico.

Il failover group lavora un gradino più in alto: raggruppa più database (su Azure SQL Managed Instance l’intera istanza), espone un listener con endpoint read-write e read-only dai nomi stabili e supporta una policy di failover automatica. Se l’applicazione non deve essere riconfigurata e più database devono spostarsi insieme, è la risposta.

Il restore geografico parte dai backup automatici replicati in un’altra area geografica: non richiede alcuna infrastruttura preparata in anticipo, ma è la via più lenta sia come RPO sia come RTO. È la rete di sicurezza, non il piano principale: è ciò che resta quando nessuna replica era attiva al momento del disastro.

Scenari ibridi e prova sul campo

Se una parte della soluzione resta on-premises o su SQL Server su Azure VM, si torna agli strumenti dell’edizione box: Always On availability group (anche distribuiti fra on-premises e Azure), Failover Cluster Instance per l’alta disponibilità di istanza e log shipping dove RPO e RTO sono generosi. Il Managed Instance link consente di replicare da SQL Server verso Managed Instance, utile sia per migrazioni sia come opzione di continuità.

Infine, una soluzione HA/DR esiste solo se è stata testata. Un failover mai provato non è una garanzia: va pianificata una prova periodica che verifichi tempi reali, riconnessione dell’applicazione, regole di firewall e private endpoint nella regione secondaria, presenza di login e permessi, dimensionamento della replica e capacità di rientro. Il risultato della prova, non la configurazione, è ciò che dimostra il rispetto di RPO e RTO.

Trappole tipiche d’esame

  • Più database devono spostarsi insieme e l’applicazione non va riconfigurata → failover group: il listener mantiene stabile il nome dell’endpoint; con active geo-replication la stringa di connessione cambia dopo il failover.
  • Serve una copia leggibile in un’altra regione e il failover lo decide un operatore → active geo-replication: granularità per singolo database e controllo manuale sono esattamente il suo profilo.
  • Continuità su Azure SQL Managed Instance → failover group: active geo-replication non è l’opzione prevista per Managed Instance, che ragiona a livello di istanza.
  • Guasto di una zona di disponibilità, senza requisito cross-region → configurazione zone-redundant: aggiungere una replica in un’altra regione risolve un problema che il testo non ha posto e alza il costo.
  • Tolleranza ampia a perdita e fermo, nessuna spesa aggiuntiva → restore geografico: corretto solo quando la domanda ammette esplicitamente RPO e RTO larghi.
  • “Il failover group è configurato, quindi siamo coperti” → prova pianificata di failover: senza un test documentato non c’è evidenza che RTO e RPO dichiarati siano raggiungibili.