Che cosa stai proteggendo, e da che cosa
Ogni domanda HA/DR del DP-300 si risolve rispondendo a tre domande implicite: qual è l’unità da proteggere (un singolo database, un gruppo di database, un’intera istanza), quale perimetro deve reggere il guasto (zona di disponibilità, regione, sito on-premises) e chi decide il failover (un operatore o la piattaforma). Su Azure SQL Database e Azure SQL Managed Instance la ridondanza dentro la regione è già inclusa nel service tier: Business Critical mantiene repliche locali e offre una secondaria leggibile, la configurazione zone-redundant distribuisce quelle repliche fra zone di disponibilità. Di conseguenza, quando lo scenario parla di geo-replication o di failover group, sta sempre parlando del livello successivo — la protezione fra regioni. Su SQL Server in Azure Virtual Machines e on-premises, invece, non c’è nulla di incluso: HA e DR si costruiscono a mano con Always On availability group, Failover Cluster Instance e log shipping.
Fra regioni: active geo-replication o failover group
L’active geo-replication si configura per singolo database. Produce una o più secondarie in altre regioni, leggibili per carichi di reporting, con replica asincrona; il failover si avvia manualmente. Il punto che l’esame verifica è la conseguenza applicativa: dopo il failover l’endpoint è quello del nuovo server, quindi la connection string va cambiata. È la scelta giusta quando serve una secondaria leggibile in una regione specifica, quando i database vanno gestiti singolarmente o quando si vuole controllare il momento esatto dello switch.
Il failover group costruisce sopra lo stesso meccanismo di replica un’astrazione diversa: raggruppa più database (su Managed Instance, l’istanza), espone un listener — un endpoint read-write e uno read-only — che resta stabile dopo il failover, e supporta una policy di failover automatica. È la risposta ogni volta che il requisito dice “l’applicazione non deve essere riconfigurata” oppure “questi database devono spostarsi insieme”. Il geo-restore dai backup replicati resta la via più lenta e va scelto solo quando lo scenario tollera esplicitamente un ripristino lungo e non chiede una secondaria pronta.
Su VM e on-premises: AG, FCI, log shipping
L’Always On availability group protegge un insieme definito di database. Le repliche in synchronous commit eliminano la perdita di dati e sono il presupposto del failover automatico, ma pagano latenza e vanno tenute vicine; quelle in asynchronous commit servono per il DR verso un’altra regione e implicano un failover forzato con possibile perdita di dati. Il listener dell’AG dà all’applicazione un nome stabile, come il listener del failover group nel mondo PaaS. Richiede un cluster Windows Server Failover Clustering sottostante.
La Failover Cluster Instance protegge invece l’intera istanza appoggiandosi ad archiviazione condivisa: esiste una sola copia dei dati, quindi non c’è secondaria leggibile e lo storage va reso resiliente per conto proprio. È la risposta quando devono sopravvivere anche gli oggetti a livello di istanza — login, job di SQL Server Agent, linked server — perché si spostano con l’istanza stessa. AG e FCI si combinano spesso: FCI per l’alta disponibilità locale, AG asincrono verso la regione di DR.
Il log shipping è la soluzione semplice, economica e a bassa frequenza: backup, copia e restore del transaction log su una pianificazione. Nessun listener, nessun failover automatico, ma un vantaggio che l’esame ama citare — il ritardo configurabile nel restore permette di recuperare da un errore logico (una DELETE sbagliata) prima che venga applicato alla secondaria.
Monitorare e riconoscere i sintomi
Il monitoraggio verifica sempre le stesse due grandezze: ritardo della replica e stato di sincronizzazione. Su Azure SQL si guardano le metriche di replica in Azure Monitor, sys.dm_geo_replication_link_status e database watcher; su AG, sys.dm_hadr_database_replica_states insieme agli Extended Events. Sintomi tipici: redo queue che cresce e secondaria che resta indietro (banda o I/O insufficienti sulla secondaria); replica in stato non sincronizzato che blocca il failover automatico; failover che non parte perché la policy è manuale, perché il grace period non è trascorso o perché il cluster ha perso il quorum. Dopo un failover, controlla sempre firewall rule, private endpoint, login/utenti e accesso alle chiavi TDE nella regione secondaria.
Trappole tipiche d’esame
- L’applicazione non deve cambiare connection string dopo il failover → failover group: il listener mantiene l’endpoint stabile. Con la sola active geo-replication l’applicazione deve puntare al nuovo server, ed è la distrazione più frequente.
- Più database devono fare failover insieme, come gruppo → failover group: l’active geo-replication ragiona per singolo database e non garantisce che si spostino contemporaneamente.
- Serve una secondaria leggibile in una regione precisa, con failover deciso da noi → active geo-replication: il failover group è pensato per l’automatismo; se il requisito insiste sul controllo manuale e per singolo database, la risposta è geo-replication.
- Devono sopravvivere job di SQL Server Agent, login e linked server → Failover Cluster Instance: l’availability group protegge i database, non gli oggetti a livello di istanza, che vanno replicati manualmente sulle altre repliche.
- Serve protezione da un errore logico, non da un guasto → log shipping con restore ritardato: geo-replication, failover group e AG replicano fedelmente anche la cancellazione sbagliata; qui serve il ritardo, o un point-in-time restore.
- Failover automatico richiesto senza perdita di dati su VM → AG in synchronous commit: con repliche asincrone il failover automatico non è possibile e quello forzato accetta perdita di dati.