1. Introduzione a SQL Server Alta disponibilità
Alta disponibilità in SQL Server Si riferisce alla capacità del sistema di rimanere operativo con tempi di inattività minimi in caso di guasti hardware, problemi software o manutenzione programmata. L'importanza dell'alta disponibilità non può essere sottovalutata. Quando i database diventano non disponibili, le organizzazioni subiscono conseguenze immediate, tra cui perdita di fatturato, riduzione della produttività e insoddisfazione dei clienti.
Sebbene High Availability (HA) e Disaster Recovery (DR) siano spesso utilizzati in modo intercambiabile, affrontano scenari di errore diversi. HA si concentra sulla riduzione al minimo dei tempi di inattività causati da errori localizzati, come crash di server o istanze, mentre DR è progettato per il ripristino da disastri su larga scala che colpiscono un intero data center o una regione.
Due parametri critici guidano la pianificazione HA:
- Recovery Time Objective (RTO) definisce il tempo di inattività massimo accettabile dopo un guasto
- Recovery Point Objective (RPO) specifica la massima perdita di dati tollerabile.
La disponibilità viene comunemente misurata in "nove": il 99.9% (tre nove) consente 8.76 ore di inattività all'anno, il 99.99% (quattro nove) consente 52.6 minuti e il 99.999% (cinque nove) limita l'inattività a soli 5.26 minuti all'anno.
2. SQL Server Panoramica delle soluzioni ad alta disponibilità
2.1 Categorie di soluzioni HA
SQL Server Le soluzioni ad alta disponibilità possono essere classificate in base a diverse dimensioni:
- Protezioni a livello di istanza rispetto a quelle a livello di database: le protezioni a livello di istanza, come le istanze del cluster di failover, proteggono intere istanze, inclusi tutti i database e gli oggetti del server, mentre le protezioni a livello di database, come i gruppi di disponibilità Always On, proteggono database specifici.
- Spostamento dati sincrono vs asincrono: lo spostamento dati sincrono garantisce una perdita di dati pari a zero, ma può introdurre latenza, mentre lo spostamento asincrono ottimizza le prestazioni ma accetta una possibile perdita di dati.
- Failover automatico vs manuale: il failover automatico riduce al minimo i tempi di inattività senza intervento manuale, mentre il failover manuale offre un maggiore controllo ma richiede l'intervento dell'amministratore.
2.2 Soluzioni HA comuni
SQL Server fornisce otto soluzioni principali ad alta disponibilità, ciascuna delle quali affronta scenari specifici:
- Gruppi di disponibilità sempre attivi
- Gruppi di disponibilità contenuti
- Gruppi di disponibilità distribuiti
- Istanze del cluster di failover
- SQL Server replicazione
- Log spedizione
- Mirroring del database
- Collegamento istanza gestita
3. Gruppi di disponibilità sempre attivi
Gruppi di disponibilità sempre attivi rappresenta SQL Serverla principale soluzione di alta disponibilità e ripristino di emergenza a livello di database, introdotta in SQL Server 2012. Consente a gruppi di database di eseguire il failover insieme come un'unica unità, fornendo al contempo repliche secondarie leggibili per l'offload delle query.
Funzionalità principali
- Supporto per un massimo di 9 repliche totali (1 primaria + 8 secondarie)
- Fino a 5 repliche in modalità commit sincrono (1 primaria + 4 secondarie)
- Failover automatico senza perdita di dati in modalità sincrona
- Repliche secondarie leggibili per lo scarico delle query
- Trasferimento del backup su repliche secondarie
- Listener del gruppo di disponibilità per il routing automatico delle connessioni
- Routing di sola lettura per le query di lettura con bilanciamento del carico
- Più database eseguono il failover insieme come gruppo
Fasi di implementazione
- Configurare il cluster WSFC (Windows Server Failover Clustering) o Linux Pacemaker
- Abilita la funzionalità Gruppi di disponibilità sempre attivi su tutti SQL Server istanze
- Assicurarsi che i database utilizzino un modello di recupero completo e dispongano di backup completi
- Creare endpoint di mirroring del database su ogni replica
- Creare il gruppo di disponibilità e aggiungere i database
- Configurare le repliche primarie e secondarie con le modalità desiderate
- Creare e configurare l'ascoltatore del gruppo di disponibilità
- Configurare il routing di sola lettura se si utilizzano secondari leggibili
- Testare le procedure di failover e verificare la connettività dell'applicazione
Ideale per
- Database mission-critical che richiedono il massimo tempo di attività
- Organizzazioni che necessitano sia di HA locale che di DR geografico
- Ambienti che richiedono capacità di lettura su scala
- Applicazioni che traggono vantaggio dall'offload delle query di reporting
- Database che richiedono protezione contro la perdita di dati pari a zero
- Applicazioni multi-database che necessitano di failover coordinato
Pro
- Nessuna perdita di dati con la modalità di commit sincrono
- Il failover automatico riduce al minimo i tempi di inattività (in genere secondi)
- I secondari leggibili riducono il carico sul primario
- Nessun requisito di archiviazione condivisa
- Supporta sia le piattaforme Windows che Linux
- Distribuzione geografica per il ripristino dopo un disastro
- Le operazioni di backup possono essere scaricate sui secondari
- Le stringhe di connessione dell'applicazione rimangono invariate dopo il failover
Contro
- Richiede Enterprise Edition per la piena funzionalità
- Edizione Standard limitata a Basic AG (1 database, 1 secondario, nessun secondario leggibile)
- Configurazione e gestione complessa
- Richiede un'infrastruttura di clustering (WSFC o Pacemaker)
- Gli oggetti a livello di istanza (accessi, lavori) richiedono la sincronizzazione manuale
- La modalità sincrona può introdurre latenza nelle transazioni
- Costi di licenza per più server
Referenze
- SQL Server Gruppi di disponibilità Always On: guida completa
- Documento ufficiale Microsoft: Panoramica dei gruppi di disponibilità Always On (SQL Server)
4. Gruppi di disponibilità contenuti
Gruppi di disponibilità contenuti, introdotti in SQL Server 2022, estende i tradizionali gruppi di disponibilità Always On sincronizzando automaticamente gli oggetti a livello di istanza tra le repliche, eliminando la necessità di replicare manualmente accessi, processi e altri oggetti a livello di server.
Funzionalità principali
- Sincronizzazione automatica degli oggetti a livello di istanza (accessi, utenti, ruoli)
- SQL Server Lavori dell'agente replicati su tutte le repliche
- Autorizzazioni del database sincronizzate automaticamente
- Tutte le funzionalità Always On AG incluse
- Failover semplificato con replica completa dell'ambiente
- Supporto per entrambe le piattaforme Windows e Linux
Fasi di implementazione
- Garantire SQL Server 2022 o successivo su tutte le istanze
- Configurare l'infrastruttura del cluster WSFC o Pacemaker
- Abilita la funzionalità Always On su tutte le istanze
- Crea un gruppo di disponibilità contenuto con l'opzione CONTENUTO
- Aggiungere database all'AG contenuto
- Creare accessi e lavori nel contesto AG
- Configurare l'ascoltatore e testare il failover
Ideale per
- Organizzazioni che desiderano un'amministrazione AG semplificata
- Ambienti con frequenti test o operazioni di failover
- Applicazioni che richiedono molti oggetti a livello di istanza
- New SQL Server 2022+ implementazioni
- Team che cercano una configurazione post-failover ridotta
Pro
- Elimina la sincronizzazione manuale di accessi e lavori
- Failover più veloce e affidabile
- Costi amministrativi ridotti
- Le applicazioni funzionano immediatamente dopo il failover
- Procedure semplificate di disaster recovery
- Tutti i vantaggi tradizionali dell'AG inclusi
Contro
- Richiede SQL Server 2022 o successivo
- Per la piena funzionalità è richiesta l'edizione Enterprise
- Non è possibile convertire gli AG tradizionali esistenti in AG contenuti
- Tutte le repliche devono supportare la funzionalità AG contenuta
- Complessità aggiuntiva rispetto agli AG tradizionali
Referenze
5. Gruppi di disponibilità distribuiti
Gruppi di disponibilità distribuiti, introdotti in SQL Server 2016, abilitare un'architettura "Availability Group of Availability Groups", collegando due AG indipendenti su cluster separati per scenari avanzati di disaster recovery e migrazione.
Funzionalità principali
- Collega due gruppi di disponibilità indipendenti
- Ogni AG mantiene il proprio cluster indipendente
- Supporto multipiattaforma (da Windows a Linux)
- Replica tra cluster senza appartenenza a cluster condivisi
- Un AG funge da primario, l'altro da secondario
- Supporta sia la modalità sincrona che quella asincrona
- Distribuzione geografica tra regioni o continenti
Fasi di implementazione
- Creare e configurare il primo gruppo di disponibilità (DAG primario)
- Creare e configurare il secondo gruppo di disponibilità (DAG secondario)
- Creare AG distribuito collegando i due AG
- Configurare la sincronizzazione dei dati tra AG
- Impostare l'ascoltatore su ogni AG per la connettività dell'applicazione
- Configurare criteri di failover e procedure di test
- Verificare la comunicazione e la replica tra cluster
Ideale per
- Ripristino di emergenza multi-regione che si estende su data center indipendenti
- Migrazione multipiattaforma da Windows a Linux o viceversa
- Scenari di cloud ibrido che si connettono in locale ad Azure
- Aggiornamenti di versione importanti che richiedono finestre di migrazione estese
- Organizzazioni con più cluster di failover indipendenti
- Le aziende globali necessitano di una replicazione che si estende su più continenti
Pro
- Disaccoppia le dipendenze del cluster tra i siti
- Consente una vera distribuzione geografica
- Supporta scenari multipiattaforma
- Ogni AG può eseguire il failover in modo indipendente
- Ideale per progetti di migrazione complessi
- Non è richiesta alcuna infrastruttura di cluster condivisa
- Può estendersi su diversi domini Windows o distribuzioni Linux
Contro
- Richiede Enterprise Edition
- Elevata complessità nella configurazione e nella gestione
- Richiede una profonda conoscenza sia del clustering che della tecnologia AG
- Più difficile da risolvere rispetto agli AG standard
- Latenza aggiuntiva per scenari interregionali
- Richiede un'attenta pianificazione delle procedure di failover
Referenze
6. Istanze del cluster di failover (FCI)
Le istanze del cluster di failover forniscono elevata disponibilità a livello di istanza utilizzando l'archiviazione condivisa e il clustering di failover di Windows Server, consentendo il failover automatico di un intero SQL Server istanza che include tutti i database e gli oggetti a livello di server.
Funzionalità principali
- Protezione a livello di istanza (tutti i database eseguono il failover contemporaneamente)
- Configurazione attiva-passiva con storage condiviso
- Nome di rete virtuale (VNN) per failover trasparente
- Failover automatico in caso di guasto del nodo attivo
- Nessuna perdita di dati (singola copia dei dati)
- Oggetti a livello di server inclusi (accessi, lavori, server collegati)
- Supporta tutto SQL Server modelli di recupero
Fasi di implementazione
- Configurare Windows Server Failover Cluster (WSFC)
- Configurare l'archiviazione condivisa (SAN, SMB, Storage Spaces Direct)
- Configurare le impostazioni del quorum del cluster
- Installazione SQL Server come istanza del cluster di failover sul primo nodo
- Aggiungere nodi aggiuntivi all'FCI
- Configurare il nome della rete virtuale e l'indirizzo IP
- Failover di prova tra i nodi del cluster
- Configurare le applicazioni client per utilizzare VNN
Ideale per
- Organizzazioni con infrastruttura di archiviazione condivisa esistente
- Ambienti che richiedono protezione a livello di istanza
- Alta disponibilità locale all'interno di un singolo data center
- Applicazioni che necessitano di eseguire il failover di tutti i database contemporaneamente
- Scenari in cui gli oggetti a livello di server devono essere protetti
- Ambienti solo Windows (Linux non supportato per FCI)
Pro
- Protezione completa a livello di istanza
- Nessuna perdita di dati garantita
- Capacità di failover automatico
- Non è necessario sincronizzare accessi o lavori
- Una singola copia dei dati riduce i costi di archiviazione.
- Supporta tutti i modelli di recupero
- Stringhe di connessione dell'applicazione invariate dopo il failover
Contro
- Richiede una costosa infrastruttura di archiviazione condivisa
- L'archiviazione condivisa è un singolo punto di errore
- Nessuna capacità di lettura su scala (solo un nodo attivo)
- Distribuzione geografica limitata a causa di vincoli di archiviazione
- Edizione standard limitata a 2 nodi
- Solo Windows (nessun supporto Linux)
- Tempo di failover più lungo rispetto agli AG (in genere minuti)
- Configurazione e gestione di storage complesse
Referenze
- SQL Server Cluster di failover: guida completa per DBA
- Documento ufficiale Microsoft: istanze del cluster di failover Always On (SQL Server)
7. SQL Server replicazione
SQL Server La replica è una tecnologia di distribuzione dei dati che copia e distribuisce i dati su più server, supportando varie topologie, dalla semplice distribuzione unidirezionale alle complesse configurazioni multi-master, sebbene venga utilizzata principalmente per la creazione di report piuttosto che come soluzione ad alta disponibilità pura.
Funzionalità principali
- Quattro tipi di replica: Snapshot, Transazionale, Merge, Peer-to-Peer
- Selezione granulare dei dati (tabelle, colonne, righe specifiche)
- Supporto per più abbonati da un singolo editore
- Topologie bidirezionali e multi-master disponibili
- Opzioni di pianificazione e sincronizzazione flessibili
- Risoluzione dei conflitti per la replica di unione
- Capacità di filtraggio con predicati WHERE
Fasi di implementazione
- Configurare il server Distributor (può essere separato o uguale al Publisher)
- Crea una pubblicazione sul database di Publisher
- Selezionare il tipo di replica in base ai requisiti
- Scegli gli articoli (tabelle, viste, stored procedure) da replicare
- Configurare il filtraggio e la trasformazione dei dati se necessario
- Impostare i database degli abbonati
- Crea abbonamenti (push o pull)
- Inizializza gli abbonamenti con snapshot
- Monitorare gli agenti di replicazione e la latenza
Ideale per
- Distribuzione dei dati a più server di reporting
- Scenari di lettura su larga scala con carichi di lavoro di reporting
- Distribuzione parziale dei dati a siti remoti
- Consolidamento dei dati da più fonti
- Scenari occasionalmente connessi (replica di unione)
- Ruolo di supporto nella strategia di ripristino in caso di disastro
Pro
- Controllo granulare sui dati replicati
- Sono supportati più abbonati
- Opzioni di topologia flessibili
- Può replicare tabelle o colonne specifiche
- Il filtraggio riduce il traffico di rete
- Supporta la replicazione eterogenea (SQL Server (a Oracle)
- Funziona con l'edizione standard
Contro
- Nessuna capacità di failover automatico
- Configurazione e gestione complessa
- Potenziale di conflitti di replicazione (unione e peer-to-peer)
- Latenza nella sincronizzazione dei dati
- Le modifiche allo schema richiedono un attento coordinamento
- Non progettato come soluzione HA primaria
- La risoluzione dei problemi può essere impegnativa
- Peer-to-Peer richiede Enterprise Edition
Referenze
- SQL Server Replicazione: guida completa per DBA
- Documento ufficiale Microsoft: SQL Server replicazione di
8. Spedizione di tronchi
Log Shipping offre una soluzione di disaster recovery e alta disponibilità con standby a caldo tramite processi automatizzati di backup, copia e ripristino del log delle transazioni, proponendo un approccio semplice ed economico per la gestione di database secondari sincronizzati.
Funzionalità principali
- Backup, copia e ripristino automatizzati tramite SQL Agent
- Supporto per più server secondari
- Intervalli di backup e ripristino configurabili
- La modalità STANDBY consente l'accesso in sola lettura al secondario
- Ripristino ritardato del registro per la protezione dal ripristino degli errori
- Server di monitoraggio per il monitoraggio centralizzato
- Supporto per la compressione del registro delle transazioni
Fasi di implementazione
- Assicurarsi che il database primario utilizzi il modello di ripristino completo
- Crea un backup completo del database primario
- Ripristina il backup sul server secondario con NORECOVERY
- Configurare la spedizione dei log sul database primario
- Specificare la cartella di backup condivisa accessibile a tutti i server
- Configurare la pianificazione del processo di backup sul primario
- Configurare i processi di copia e ripristino sul secondario
- Facoltativamente, configurare il server di monitoraggio
- Procedure di failover di prova
Ideale per
- Soluzioni di ripristino post-disastro economicamente vantaggiose
- Organizzazioni con licenza Standard Edition
- Scenari che tollerano minuti di perdita di dati
- Ambienti confortevoli con failover manuale
- Ripristino ritardato per esigenze di protezione dagli errori
- Segnalazione dei carichi di lavoro tramite modalità STANDBY
- Semplici requisiti DR senza infrastrutture complesse
Pro
- Configurazione e funzionamento semplici
- Basso costo (supporto per l'edizione standard)
- Sono supportati più server secondari
- Il ritardo configurabile protegge dagli errori logici
- Segnalazione di sola lettura in modalità STANDBY
- Tollera un'elevata latenza di rete
- Impatto minimo sul server primario
- Tecnologia consolidata e comprovata
Contro
- Nessuna capacità di failover automatico
- È necessario configurare separatamente per ogni database
- Ritardo di sincronizzazione (da minuti a ore)
- Potenziale perdita di dati in base all'intervallo di backup
- Il failover manuale aumenta l'RTO
- Richiede SQL Server Agente in esecuzione su tutti i server
- Database secondari non accessibili durante il ripristino del registro
- Le applicazioni richiedono modifiche alla stringa di connessione dopo il failover
Referenze
- SQL Server Log Shipping: guida completa per DBA
- Documento ufficiale Microsoft: Informazioni sulla spedizione dei log (SQL Server)
9. Mirroring del database
Il mirroring del database è una soluzione di alta disponibilità a livello di database obsoleta che non ha ricevuto miglioramenti da allora SQL Server 2012, sebbene rimanga disponibile nelle versioni attuali. Microsoft consiglia vivamente di migrare ai Gruppi di disponibilità Always On per tutte le nuove distribuzioni.
Funzionalità principali
- Architettura del server principale e mirror
- Server di controllo opzionale per il failover automatico
- Due modalità operative: Alta sicurezza e Alte prestazioni
- Supporto per operazioni sincrone e asincrone
- Capacità di riparazione automatica delle pagine
- Protezione a livello di database
- Supporto di crittografia per la trasmissione dei dati
Fasi di implementazione
- Assicurarsi che il database utilizzi un modello di recupero completo
- Crea un backup completo e ripristina il server mirror con NORECOVERY
- Creare endpoint di mirroring su principal e mirror
- Configurare i certificati per l'autenticazione
- Stabilire una sessione di mirroring tra i server
- Facoltativamente, configurare il server di controllo per il failover automatico
- Imposta la modalità operativa (Alta sicurezza o Alte prestazioni)
- Procedure di failover di prova
Ideale per
- Sistemi legacy che utilizzano già il mirroring del database
- Mantenimento delle configurazioni esistenti fino alla migrazione possibile
- Nessun altro scenario consigliato (la funzionalità è obsoleta)
Pro
- Failover automatico rapido in modalità High Safety con witness
- Nessuna perdita di dati in modalità di sicurezza elevata
- Riparazione automatica della pagina dal partner
- Più semplice dei gruppi di disponibilità per un singolo database
- Supporta la crittografia per la trasmissione
- Aggiornamenti continui con tempi di inattività minimi
Contro
- Obsoleto da SQL Server 2012 (potrebbe essere rimosso)
- Configurazione e failover per database
- Nessuno specchio leggibile (nessuna capacità di lettura della scala)
- Ogni database esegue il failover in modo indipendente
- Aggiornamenti della stringa di connessione richiesti dopo il failover
- Limitato a due server (principale e mirror)
- Nessun miglioramento o nuova funzionalità
- Microsoft consiglia la migrazione ad Always On AG
Referenze
10. Collegamento istanza gestita
Il collegamento dell'istanza gestita crea una connessione ibrida tra SQL Server e Azure SQL Managed Instance che utilizza la tecnologia dei gruppi di disponibilità distribuiti, consentendo la replica dei dati quasi in tempo reale per scenari di disaster recovery, migrazione e integrazione cloud.
Funzionalità principali
- Replicazione quasi in tempo reale mediante tecnologia AG distribuita
- Replicazione unidirezionale (SQL Server 2016-2019 ad Azure)
- Replica bidirezionale con failback (SQL Server 2022 +)
- Un database per collegamento (sono supportati più collegamenti)
- Repliche leggibili su Azure SQL Managed Instance
- Opzione di replica DR passiva senza licenza
- Migrazione online con tempi di inattività minimi
Fasi di implementazione
- Preparare SQL Server ambiente (VPN o ExpressRoute su Azure)
- Configurare l'istanza gestita di Azure SQL
- Abilita la funzione Always On AG su SQL Server
- Crea endpoint di mirroring del database
- Scambia certificati tra SQL Server e MI
- Crea un collegamento all'istanza gestita utilizzando SSMS o script
- Convalida la replicazione e la sincronizzazione
- Configurare il routing di sola lettura se utilizzato per la scala di lettura
- Procedure di failover di prova
Ideale per
- Ripristino di emergenza ibrido con backup secondario basato su cloud
- Migrazione online ad Azure SQL Managed Instance
- Trasferimento di analisi e reportistica ad Azure
- Organizzazioni che adottano una strategia di cloud ibrido
- Scenari che richiedono l'integrazione del servizio Azure
- Ottimizzazione dei costi con DR passivo senza licenza
Pro
- Migrazione ad Azure con le massime prestazioni e tempi di inattività minimi.
- Vera migrazione online al livello Business Critical
- Failover bidirezionale con SQL Server 2022+
- La replica passiva di ripristino d'emergenza senza licenza riduce i costi
- Integrazione con i servizi di Azure senza migrazione completa
- Capacità di scalabilità in lettura tramite repliche di Azure
- Backup automatici sul lato Azure
- Distribuzione geografica nelle regioni di Azure
Contro
- Limitazione di un database per collegamento
- Non è possibile utilizzarlo con gruppi di failover su MI
- Database di sistema non replicati
- Gli oggetti a livello di istanza richiedono la sincronizzazione manuale
- SQL Server 2016-2019 solo andata (nessun failback)
- Costi di Azure per le istanze gestite
- Requisiti di connettività di rete (VPN/ExpressRoute)
- Limitazioni delle funzionalità (tabelle di file, flussi di file non supportati)
Referenze
11. Confronto tra soluzioni ad alta disponibilità
11.1 Tabella di confronto delle funzionalità
| Caratteristica | Sempre attivo AG | AG contenuto | AG distribuito | FCI | replicazione | Log spedizione | Mirroring | MI Link |
|---|---|---|---|---|---|---|---|---|
| Edizione | Ent/Std | Ent/Std | Ent | Ent/Std | Ent/Std | Ent/Std | Ent/Std | Ent/Std |
| Livello di protezione | Banca Dati | Database+Istanza | Banca Dati | Instance | Database/Oggetti | Banca Dati | Banca Dati | Banca Dati |
| Sincronizzazione dati | Sincronizzato/Asincrono | Sincronizzato/Asincrono | Sincronizzato/Asincrono | diviso | Asincrono | Asincrono | Sincronizzato/Asincrono | Asincrono |
| Failover automatico | Si | Si | Si | Si | Non | Non | Si | Non |
| Scala di lettura | Si | Si | Si | Non | Si | Limitato | Non | Si |
| RTO | secondi | secondi | secondi | Minuti | Manuale | Manuale | secondi | Manuale |
| RPO | Zero/Min | Zero/Min | Zero/Min | Zero | Minimo | Minuti | Zero/Min | Minimo |
| Stato di supporto | Active | Active | Active | Active | Active | Active | deprecato | Active |
11.2 Scegli la soluzione HA
Nella scelta della soluzione, considerare i seguenti fattori:
- Le considerazioni di budget hanno un impatto significativo sulla scelta della soluzione: i requisiti dell'edizione Enterprise incidono sui costi di licenza, mentre le esigenze infrastrutturali variano da costosi sistemi di storage condiviso per gli FCI a server standard per i gruppi di disponibilità.
- La complessità varia in modo sostanziale: il Log Shipping offre l'implementazione più semplice, mentre i Distributed Availability Group richiedono competenze approfondite.
- I requisiti RTO guidano le scelte tecnologiche. I secondi di inattività richiedono gruppi di disponibilità Always On o FCI con failover automatico. La tolleranza in minuti consente soluzioni di failover manuale come il Log Shipping.
- I requisiti RPO sono altrettanto importanti: la perdita di dati pari a zero impone soluzioni sincrone, mentre la tolleranza in minuti consente il Log Shipping.
- I vincoli infrastrutturali, le esigenze di scalabilità, i requisiti di distribuzione geografica e gli scenari cloud ibridi influenzano tutti la scelta della soluzione ottimale.
12. Migliori pratiche per SQL Server Alta disponibilità
12.1 Pianificazione e progettazione
Valutare i requisiti aziendali attraverso un'attenta analisi di RTO e RPO per ciascun database. Scegliere soluzioni appropriate che soddisfino i requisiti, anziché optare per impostazione predefinita per le opzioni più sofisticate. Pianificare sia l'alta disponibilità locale che il ripristino di emergenza geografico utilizzando approcci a livelli. Documentare l'architettura in modo esaustivo, includendo diagrammi di rete, procedure di failover e manuali di ripristino.
12.2 Linee guida per l'implementazione
Testare regolarmente le procedure di failover tramite test programmati e simulazioni di guasti per convalidare SQL Server soluzioni ad alta disponibilità e prontezza del team. Monitora costantemente lo stato di salute e le prestazioni utilizzando SQL Serverstrumenti integrati come SQL Server Profiler e DMV. Configura avvisi completi per ritardi di sincronizzazione, eventi di failover e degrado dello stato. Mantieni SQL Server strategie di backup Nonostante l'implementazione dell'alta disponibilità, i backup rimangono l'ultima linea di difesa contro la corruzione logica e le eliminazioni accidentali. Mantenere i sistemi aggiornati con aggiornamenti cumulativi, patch di sicurezza e aggiornamenti del firmware. Convalidare periodicamente le procedure di ripristino tramite ripristini effettivi e test delle applicazioni e saper gestire scenari come database bloccati in modalità di ripristino.
12.3 Monitoraggio e manutenzione
Utilizza strumenti come SQL Server Activity Monitor, SQL Server performance Monitore viste di gestione dinamica ampiamente per il monitoraggio dello stato di salute ed esecuzione DBCC CHECKDB regolarmente per verificare l'integrità del database. Sfruttare la Dashboard Always On per una valutazione visiva dello stato di salute del Gruppo di Disponibilità. Monitorare attentamente il ritardo di sincronizzazione, in particolare per le repliche asincrone e il Log Shipping. Monitorare meticolosamente gli eventi di failover utilizzando SQL Server Eventi estesi e analizzare le cause dei modelli. Stabilire valori di riferimento delle prestazioni per il normale funzionamento e monitorare le deviazioni che indicano potenziali problemi. Eseguire revisioni periodiche della pianificazione della capacità per garantire che l'infrastruttura supporti carichi di lavoro crescenti.
13. FAQ
D: Qual è la differenza tra alta disponibilità e ripristino di emergenza in SQL Server?
R: L'elevata disponibilità riduce al minimo i tempi di inattività dovuti a guasti locali all'interno di un data center, in genere con failover automatico e RTO in pochi secondi o minuti. Il disaster recovery protegge da catastrofi regionali, in genere con failover manuale e RTO più lunghi, ma coprendo eventi che interessano intere strutture.
D: Qual è la differenza tra soluzioni ad alta disponibilità (HA) e soluzioni Read-Scale?
A: Le soluzioni di alta disponibilità garantiscono che i database rimangano accessibili anche in caso di guasti, concentrandosi su uptime e funzionalità di failover automatico. Le soluzioni di scalabilità in lettura migliorano le prestazioni delle query distribuendo i carichi di lavoro di sola lettura su più repliche del database, concentrandosi su throughput e tempi di risposta. Sebbene queste soluzioni abbiano scopi diversi, la stessa tecnologia, come gli Always On Availability Group, può offrire entrambi i vantaggi contemporaneamente: le repliche secondarie leggibili offrono funzionalità di scalabilità in lettura e fungono anche da destinazioni di failover per garantire l'alta disponibilità.
Q: Quale? SQL Server Quale soluzione ad alta disponibilità è la migliore per le mie esigenze?
A: La soluzione migliore dipende dagli obiettivi RTO e RPO, dal budget, dalla disponibilità delle edizioni, dall'infrastruttura e dalle competenze. Always On Availability Groups è adatto alla maggior parte degli scenari aziendali, mentre Log Shipping funziona bene in ambienti in cui il costo è un fattore critico. Valuta i requisiti in base alla tabella comparativa.
D: Per utilizzare Always On Availability Group è necessaria l'edizione Enterprise?
R: La Standard Edition supporta i Basic Availability Group (BAG) con limitazioni significative: un database per gruppo, una replica secondaria e nessun database secondario leggibile. Per usufruire di tutte le funzionalità, inclusi più database, otto database secondari e repliche leggibili, è richiesta la Enterprise Edition.
D: Posso usare la spedizione dei registri con SQL Server Edizione standard?
R: Sì, Log Shipping è pienamente supportato nella Standard Edition, il che lo rende una soluzione di disaster recovery interessante ed economicamente vantaggiosa per le organizzazioni che non dispongono di una licenza Enterprise Edition.
D: Qual è la differenza tra Always On Availability Groups e Database Mirroring?
R: Il mirroring del database è obsoleto e funziona a livello di singolo database senza accesso secondario in lettura. Always On Availability Groups supporta gruppi di database, fino a otto database secondari, repliche leggibili e monitoraggio avanzato. Microsoft consiglia di migrare ad Always On.
D: Come faccio a scegliere tra istanze del cluster di failover e gruppi di disponibilità?
R: Scegliete gli FCI per la protezione a livello di istanza con un'infrastruttura di storage condivisa. Scegliete i Gruppi di Disponibilità per la protezione a livello di database, capacità di lettura su larga scala e distribuzione geografica senza storage condiviso. Le organizzazioni spesso combinano entrambe le soluzioni per una protezione completa.
D: Posso combinare più SQL Server soluzioni ad alta disponibilità?
R: Sì, è comune combinare soluzioni. Le FCI possono fungere da repliche dei Gruppi di Disponibilità, fornendo HA locale a livello di istanza e DR geografico a livello di database. Il Log Shipping può integrare i Gruppi di Disponibilità per una protezione remota aggiuntiva. È consigliabile testare attentamente le configurazioni combinate.
D: Qual è la differenza tra replica sincrona e asincrona?
R: La replica sincrona attende la conferma secondaria prima di eseguire il commit, garantendo zero perdite di dati ma potenzialmente introducendo latenza. La replica asincrona procede senza attese, ottimizzando le prestazioni ma creando possibili perdite di dati durante il failover.
D: Ho ancora bisogno di backup se ho SQL Server alta disponibilità configurata?
R: Assolutamente sì. L'alta disponibilità protegge da guasti hardware, ma non da danneggiamenti logici, eliminazioni accidentali o azioni dannose che si replicano su tutte le copie. I backup rimangono essenziali per il ripristino puntuale e i requisiti di conformità.
D: Ho ancora bisogno di backup se ho SQL Server alta disponibilità configurata?
R: Assolutamente sì. L'alta disponibilità protegge da guasti hardware, ma non può proteggere da danneggiamenti del database, eliminazioni accidentali o azioni dannose. I backup rimangono essenziali per il ripristino puntuale e i requisiti di conformità. Nei casi in cui i file del database si corrompono e i backup non siano disponibili o siano anch'essi corrotti, è necessario ricorrere a soluzioni specializzate. Software di riparazione del database SQL può aiutare a recuperare dati da file MDF, NDF e di backup danneggiati.
D: Che cos'è un gruppo di disponibilità contenuto e in che cosa si differenzia da un normale gruppo di disponibilità?
A: Gruppi di disponibilità contenuti, introdotti in SQL Server 2022, sincronizzano automaticamente gli oggetti a livello di istanza come accessi, processi e metadati. I gruppi di disponibilità standard sincronizzano solo gli oggetti del database, richiedendo la replica manuale degli oggetti dell'istanza.
D: Posso replicare i dati da SQL Server ad Azure SQL Managed Instance?
A: Sì, Managed Instance Link fornisce la replica ibrida tra SQL Server e Azzurro. SQL Server 2016-2019 supporta la replica unidirezionale, mentre SQL Server 2022+ consente la replica bidirezionale con failback per il disaster recovery, la migrazione e gli scenari ibridi.
D: Cosa succede a SQL Server Lavori dell'agente durante il failover?
A: Con i gruppi di disponibilità tradizionali, i processi devono essere creati manualmente su repliche secondarie. Gruppi di disponibilità contenuti (SQL Server 2022+) sincronizzano automaticamente i job. Le istanze del cluster di failover includono i job come parte della protezione a livello di istanza.
14. CONCLUSIONE
SQL Server Fornisce soluzioni complete ad alta disponibilità che soddisfano esigenze diverse, dai database dipartimentali ai sistemi aziendali mission-critical. Ogni soluzione offre funzionalità e compromessi distinti che gli amministratori di database devono comprendere per prendere decisioni consapevoli.
Always On Availability Groups rappresenta la tecnologia di punta per le implementazioni moderne, con Contained Availability Groups che semplifica l'amministrazione e Distributed Availability Groups che abilita scenari multipiattaforma sofisticati. Failover Cluster Instances continua a soddisfare le esigenze di protezione a livello di istanza, mentre Log Shipping rimane rilevante per scenari sensibili ai costi. Managed Instance Link apre possibilità ibride cloud che collegano l'ambiente on-premise. SQL Server con Azure.
L'abbinamento delle soluzioni alle specifiche esigenze aziendali rappresenta il fattore critico di successo. Non esiste un approccio universale. Le organizzazioni devono valutare attentamente i requisiti RTO e RPO, i vincoli di budget, le capacità infrastrutturali e le competenze amministrative. Spesso, l'architettura migliore combina più soluzioni per una protezione completa. Valutate come la vostra strategia HA si allinea con i piani di adozione del cloud più ampi e consultate articoli dedicati per una guida dettagliata all'implementazione, al fine di garantire la vostra SQL Server l'infrastruttura fornisce l'affidabilità di cui la tua azienda ha bisogno.
L'autore
Yuan Sheng è un amministratore di database senior (DBA) con oltre 10 anni di esperienza in SQL Server ambienti e gestione di database aziendali. Ha risolto con successo centinaia di scenari di ripristino di database in aziende di servizi finanziari, sanitari e manifatturiere.
Yuan è specializzato in SQL Server Ripristino di database, soluzioni ad alta disponibilità e ottimizzazione delle prestazioni. La sua vasta esperienza pratica include la gestione di database multi-terabyte, l'implementazione di gruppi di disponibilità Always On e lo sviluppo di strategie di backup e ripristino automatizzate per sistemi aziendali mission-critical.
Grazie alla sua competenza tecnica e al suo approccio pratico, Yuan si concentra sulla creazione di guide complete che aiutano gli amministratori di database e i professionisti IT a risolvere problemi complessi SQL Server sfide in modo efficiente. Si mantiene aggiornato con le ultime SQL Server versioni e le tecnologie di database in continua evoluzione di Microsoft, testando regolarmente gli scenari di ripristino per garantire che le sue raccomandazioni riflettano le migliori pratiche del mondo reale.
Hai domande su SQL Server recupero o hai bisogno di ulteriore assistenza per la risoluzione dei problemi del database? Yuan accoglie feedback e suggerimenti per migliorare queste risorse tecniche.