Guida alle soluzioni Microsoft SQL Server AlwaysOn
per la disponibilità elevata e il ripristino di emergenza
Autore: LeRoy Tuttle Jr. (Microsoft)
Collaboratori: Cephas Lin (Microsoft), Justin Erickson (Microsoft), Lindsey Allen (Microsoft),
Min He (Microsoft), Sanjay Mishra (Microsoft)
Revisori: Alexei Khalyako (Microsoft), Allan Hirt (SQLHA), Ayad Shammout (Caregroup),
Benjamin Wright-Jones (Microsoft), Charles Matthews (Microsoft), David P. Smith (ServiceU),
Juergen Thomas (Microsoft), Kevin Farlee (Microsoft), Shahryar G. Hashemi (Motricity),
Wolfgang Kutschera (Bwin Party)
Data di pubblicazione:
gennaio 2012
Contesto di applicazione: SQL Server 2012
Riepilogo: in questo white paper viene descritto come ridurre il tempo di inattività pianificato e non
pianificato, ottimizzare la disponibilità delle applicazioni e implementare protezione dati utilizzando le
soluzioni per la disponibilità elevata e il ripristino di emergenza di SQL Server 2012 AlwaysOn.
Un obiettivo fondamentale del documento è stabilire un contesto comune per le discussioni correlate
tra parti interessate aziendali, responsabili delle decisioni tecniche, architetti di sistema, ingegneri
infrastrutturali e amministratori di database.
Il contenuto è suddiviso in due parti principali:
Concetti di disponibilità elevata e ripristino di emergenza. Viene fornita una breve descrizione dei
principi guida e delle sfide che riguardano pianificazione, gestione e misurazione degli obiettivi aziendali
di un ambiente di database a disponibilità elevata. Alla descrizione segue una rapida panoramica delle
funzionalità di disponibilità elevata e ripristino di emergenza delle soluzioni SQL Server 2012 AlwaysOn
e Windows Server.
Livelli di protezione di SQL Server AlwaysOn. Viene fornita una descrizione più approfondita di funzionalità,
logica e dipendenze dei livelli di protezione offerti da una soluzione SQL Server AlwaysOn. Vengono
inoltre illustrate le funzionalità di disponibilità dell'infrastruttura, protezione a livello di istanza di SQL
Server e a livello di database e delle applicazioni livello dati.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
i
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
ii
Copyright
Il documento viene fornito “com'è”. Le informazioni e le opinioni espresse nel presente documento,
inclusi gli URL e altri riferimenti a siti Web, possono essere soggette a modifiche senza preavviso.
L'utente accetta di utilizzarlo a proprio rischio.
Alcuni esempi raffigurati in questo documento sono forniti a scopo puramente illustrativo e sono fittizi.
Nessuna associazione o connessione reale è intenzionale o può essere desunta.
Il presente documento non implica la concessione di alcun diritto di proprietà intellettuale relativo ai
prodotti Microsoft. È possibile copiare e utilizzare questo documento per fini di riferimento interno.
© 2012 Microsoft. Tutti i diritti sono riservati.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
iii
Sommario
Concetti di disponibilità elevata e ripristino di emergenza ................................. 1
Il concetto di disponibilità elevata ............................................................................................................ 1
Tempo di inattività pianificato e non pianificato .................................................................................................................... 1
Disponibilità ridotta ................................................................................................................................................................ 2
Quantificazione del tempo di inattività .................................................................................................... 3
Obiettivi di recupero ............................................................................................................................................................... 3
Giustificazione del ROI o dei costi derivati da mancate opportunità ...................................................................................... 3
Monitoraggio dell'integrità della disponibilità ........................................................................................................................ 4
Pianificazione del ripristino di emergenza .............................................................................................................................. 4
Panoramica: disponibilità elevata con Microsoft SQL Server 2012 .......................................................... 5
SQL Server AlwaysOn .............................................................................................................................................................. 5
Riduzione significativa del tempo di inattività pianificato ...................................................................................................... 6
Eliminazione di hardware inattivo e miglioramento dell'efficienza dei costi e delle prestazioni.................................................... 6
Facilità di distribuzione e gestione.......................................................................................................................................... 6
Funzionalità RPO e RTO a confronto ....................................................................................................................................... 6
Livelli di protezione di SQL Server AlwaysOn ...................................................... 8
Disponibilità dell'infrastruttura................................................................................................................. 9
Sistema operativo Windows ................................................................................................................................................... 9
Windows Server Failover Clustering ..................................................................................................................................... 10
Procedura guidata di convalida cluster WSFC....................................................................................................................... 12
Modalità di quorum e configurazione del voto nel WSFC .................................................................................................... 13
Ripristino di emergenza del cluster WSFC tramite quorum forzato ..................................................................................... 16
Protezione a livello di istanza di SQL Server ........................................................................................... 18
Miglioramenti alla disponibilità - Istanze di SQL Server ........................................................................................................ 18
Istanze del cluster di failover AlwaysOn ............................................................................................................................... 19
Disponibilità dei database....................................................................................................................... 21
Gruppi di disponibilità AlwaysOn .......................................................................................................................................... 21
Failover del gruppo di disponibilità ...................................................................................................................................... 23
Listener del gruppo di disponibilità ...................................................................................................................................... 25
Miglioramenti alla disponibilità - Database .......................................................................................................................... 27
Consigli sulla connettività client ............................................................................................................. 28
Conclusione ......................................................................................................29
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
iv
Concetti di disponibilità elevata e ripristino di emergenza
È possibile scegliere la migliore tecnologia di database da utilizzare come base per una soluzione per la
disponibilità elevata e il ripristino di emergenza quando tutte le parti interessate condividono una comune
comprensione degli obiettivi, delle problematiche e dei principi guida aziendali correlati in termini di
pianificazione, gestione e misurazione degli obiettivi di tempo di recupero (RTO) e di punto di recupero
(RPO).
I lettori che hanno familiarità con questi concetti possono passare direttamente alla sezione
Panoramica: disponibilità elevata con Microsoft SQL Server 2012 di questo documento.
Il concetto di disponibilità elevata
Per un'applicazione software o un servizio specifico, in definitiva la disponibilità elevata viene misurata
in termini di esperienza e aspettative dell'utente finale. L'impatto aziendale tangibile e percepito del
tempo di inattività può essere espresso in termini di perdita di informazioni, danni alla proprietà, riduzione
della produttività, costi derivati da mancate opportunità, danni contrattuali o perdita di avviamento.
L'obiettivo principale di una soluzione per la disponibilità elevata è attenuare o ridurre al minimo
l'impatto del tempo di inattività. L'implementazione di una solida strategia in questo senso deve creare
un equilibrio ottimale tra le esigenze in termini di processi aziendali e contratti di servizio (SLA)
e funzionalità tecniche e costi dell'infrastruttura.
Una piattaforma è considerata a elevata disponibilità in base al contratto e alle aspettative di clienti
e parti interessate. È possibile esprimere la disponibilità di un sistema con il calcolo seguente.
πππππ ππ ππ‘π‘ππ£ππ‘à πππππ‘π‘ππ£π
× 100%
πππππ ππ ππ‘π‘ππ£ππ‘à ππππ£ππ π‘π
Il valore risultante è spesso espresso dagli addetti ai lavori del settore come quantità di 9 (percentuali
tendenti al 100%) che la soluzione è in grado di fornire. Tale valore corrisponde a un numero annuo di
minuti di possibile tempo di attività o, viceversa, di minuti di tempo di inattività.
Numero di 9
2
3
4
5
Percentuale di disponibilità
99%
99.9%
99.99%
99.999%
Tempo di inattività annuo totale
3 giorni, 15 ore
8 ore, 45 minuti
52 minuti, 34 secondi
5 minuti, 15 secondi
Tempo di inattività pianificato e non pianificato
I periodi di interruzione del sistema sono previsti e pianificati o costituiscono il risultato di un problema
imprevisto. Se gestito in modo appropriato, il tempo di inattività non deve essere considerato
negativamente. Esistono due tipi principali di tempo di inattività prevedibile:
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
1
ο·
Manutenzione pianificata. Viene preannunciato e coordinato un certo intervallo di tempo per attività
di manutenzione pianificata, come applicazione di patch software, aggiornamenti hardware,
aggiornamenti delle password, reindicizzazione offline, caricamento di dati o prova delle procedure
di ripristino di emergenza. Con procedure operative intenzionali e ben gestite è possibile ridurre al
minimo il tempo di inattività e prevenire la perdita di dati. Le attività di manutenzione pianificata
possono essere considerate un investimento necessario per impedire o ridurre l'impatto di altri
scenari di interruzione non pianificati e potenzialmente più gravi.
ο·
Periodo di interruzione non pianificato. A livello di sistema, infrastruttura o processo possono
verificarsi errori e guasti non pianificati né controllabili, oppure prevedibili ma ritenuti poco
probabili, oppure considerati di impatto accettabile. Con una solida soluzione per la disponibilità
elevata è possibile rilevare questi tipi di errori, ripristinare automaticamente il sistema in seguito
all'interruzione e ristabilire la tolleranza di errore.
Nella definizione dei contratti di servizio (SLA) per la disponibilità elevata è opportuno calcolare
indicatori di prestazioni chiave (KPI) separati per le attività di manutenzione pianificata e il tempo di
inattività non pianificato. Questo approccio consente di bilanciare l'investimento nelle attività di
manutenzione pianificata con il vantaggio di evitare tempi di inattività non pianificati.
Disponibilità ridotta
La disponibilità elevata non deve essere considerata nei termini assoluti di “tutto o niente”. In alternativa
a un totale periodo di interruzione, l'utente finale spesso accetta una parziale disponibilità del sistema,
funzionalità limitate o prestazioni ridotte. I diversi gradi di disponibilità possibili sono i seguenti:
ο·
Operazioni di sola lettura e posticipate. Durante un periodo di manutenzione o un ripristino di
emergenza per fasi, il recupero dei dati è ancora possibile, ma potrebbero essere temporaneamente
interrotti o accodati nuovi flussi di lavoro e l'elaborazione in background.
ο·
Latenza dei dati e velocità di risposta delle applicazioni. A causa di un carico di lavoro elevato, di un
backlog di elaborazione o di un malfunzionamento parziale della piattaforma, risorse hardware
limitate potrebbero risultare sovraccariche o sottodimensionate. Una situazione del genere può
influire sull'esperienza utente ma permette il normale svolgimento delle attività, sia pure in modo
meno produttivo.
ο·
Errori parziali, temporanei o imminenti. La solidità nella logica dell'applicazione o nello stack
dell'hardware assicura nuovi tentativi o attività di autocorrezione a ogni errore riscontrato.
È possibile che questi tipi di problemi si manifestino all'utente finale sotto forma di latenza dei dati
o scarsa velocità di risposta delle applicazioni.
ο·
Errore end-to-end parziale. Le interruzioni pianificate o non pianificate possono verificarsi in modo
non grave all'interno di livelli verticali dello stack della soluzione (infrastruttura, piattaforma
e applicazione) oppure a livello orizzontale tra componenti funzionali diversi. L'esperienza utente
può essere parzialmente positiva o rivelare un peggioramento delle prestazioni, in base alle
funzionalità o ai componenti interessati.
L'accettabilità di questi scenari non ottimali deve essere considerata parte di una gamma di livelli di
disponibilità ridotta che possono implicare fino all'interruzione completa e costituire passaggi intermedi
di un ripristino di emergenza per fasi.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
2
Quantificazione del tempo di inattività
Quando si verifica un periodo di inattività, pianificato o non pianificato, il principale obiettivo aziendale
è riportare il sistema online e ridurre al minimo la perdita di dati. Ogni minuto di tempo di inattività
implica costi diretti e indiretti. Nel caso di periodi di inattività non pianificati, è opportuno bilanciare il
tempo e l'impegno necessari a determinare le cause dell'interruzione, l'attuale stato del sistema
e I passaggi richiesti per ripristinarlo in seguito all'interruzione.
In un momento predeterminato durante un periodo di interruzione, si impone la decisione aziendale di
fermare la ricerca delle cause dell'interruzione o l'esecuzione delle attività di manutenzione, ripristinare
il sistema in seguito all'interruzione riportandolo online e, se necessario, ristabilire la tolleranza di
errore.
Obiettivi di recupero
La ridondanza dei dati è una componente fondamentale di una soluzione di database a disponibilità
elevata. L'attività transazionale che avviene sull'istanza di SQL Server primaria viene applicata in modo
sincrono o asincrono a una o più istanze secondarie. Quando si verifica un'interruzione, è possibile che
le transazioni in corso vengano sottoposte a rollback o vadano perdute sulle istanze secondarie a causa
del ritardo nella propagazione dei dati.
È possibile misurare l'impatto di questa situazione e definire obiettivi di recupero in termini di tempo
necessario per ripristinare le normali attività e di durata della latenza nell'ultima transazione recuperata,
come descritto di seguito.
ο·
Obiettivo del tempo di recupero (RTO). Si tratta della durata dell'interruzione. L'obiettivo iniziale
è riportare il sistema online almeno nelle funzionalità di sola lettura per facilitare l'analisi del
problema. Tuttavia, l'obiettivo primario è ripristinare la piena operatività fino al punto in cui
possono avere luogo nuove transazioni.
ο·
Obiettivo del punto di recupero (RPO). Questo concetto viene spesso definito come misura della
perdita di dati accettabile. Si tratta della latenza o del gap temporale tra l'ultima transazione di dati
di cui è stato eseguito il commit prima dell'errore e i dati più recenti recuperati dopo l'errore. La
perdita di dati effettiva può variare in base al carico di lavoro del sistema al momento dell'errore, al
tipo di errore e al tipo di soluzione per la disponibilità elevata utilizzata.
I valori di RTO e RPO vanno utilizzati come obiettivi che indicano la tolleranza aziendale del tempo di
inattività e della perdita di dati accettabile e come metriche per il monitoraggio dell'integrità della
disponibilità.
Giustificazione del ROI o dei costi derivati da mancate opportunità
I costi aziendali legati al tempo di inattività possono essere di natura finanziaria o assumere la forma di
avviamento dei clienti. Questi costi possono accumularsi nel tempo o essere prodotti in un determinato
momento durante il periodo di interruzione. Oltre a preventivare i costi derivanti da un'interruzione con
uno specifico tempo di recupero e uno specifico punto di recupero dei dati, è anche possibile calcolare
gli investimenti richiesti nei processi aziendali e nell'infrastruttura per raggiungere gli obiettivi RTO
e RPO o per evitare completamente il periodo di interruzione. Aspetti da considerare per la valutazione
degli investimenti:
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
3
ο·
Possibilità di evitare il tempo di inattività. I costi di ripristino a seguito di un'interruzione vengono
del tutto evitati se l'interruzione non si verifica. Gli investimenti includono il costo di hardware
o infrastrutture ridondanti e a tolleranza di errore, la distribuzione dei carichi di lavoro tra punti di
errore isolati e la pianificazione del tempo di inattività dedicato alla manutenzione preventiva.
ο·
Automazione del ripristino. Se si verifica un errore di sistema, è possibile ridurre in modo
sostanziale l'impatto del tempo di inattività sull'esperienza utente implementando funzionalità di
ripristino automatiche e trasparenti.
ο·
Utilizzo delle risorse. L'infrastruttura secondaria o di standby può rimanere inattiva, in attesa di
un'interruzione. Può inoltre essere sfruttata per i carichi di lavoro di sola lettura o per migliorare le
prestazioni complessive del sistema tramite la distribuzione dei carichi di lavoro su tutto l'hardware
disponibile.
Per specifici obiettivi RTO e RPO, gli investimenti necessari per la disponibilità e il recupero, combinati
con i costi preventivati del tempo di inattività, possono essere espressi e giustificati in funzione del
tempo. Durante un'interruzione effettiva, questo approccio consente di adottare decisioni in base ai
costi e al tempo di inattività trascorso.
Monitoraggio dell'integrità della disponibilità
Da un punto di vista operativo, durante un periodo di interruzione effettivo non è opportuno cercare di
considerare in tempo reale tutte le variabili pertinenti e calcolare il ROI o i costi derivati da mancate
opportunità. Monitorare invece la latenza dei dati sulle istanze di standby come indicatore dell'RPO
previsto.
Durante un eventuale periodo di interruzione, è poi opportuno limitare il tempo iniziale dedicato
all'analisi della causa principale e concentrarsi invece sulla convalida dell'integrità dell'ambiente di
ripristino, basandosi successivamente sui log di sistema dettagliati e sulle copie secondarie dei dati per
un'analisi approfondita.
Pianificazione del ripristino di emergenza
Mentre le misure per assicurare la disponibilità elevata tendono a impedire che si verifichi
un'interruzione, le procedure di ripristino di emergenza riguardano le attività necessarie a ristabilire la
disponibilità elevata dopo il periodo di interruzione.
Per quanto possibile, le procedure di ripristino di emergenza e le responsabilità devono essere definite
prima del verificarsi di un'effettiva interruzione. In base al monitoraggio e agli avvisi attivi, la decisione di
avviare un piano di failover e ripristino automatico o manuale deve essere associata a soglie predeterminate
di RTO e RPO. In un piano di ripristino di emergenza affidabile devono essere tenuti in considerazione gli
aspetti seguenti:
ο·
Granularità dell'errore e del ripristino. In base alla posizione e al tipo di errore è possibile
intraprendere azioni correttive a livelli diversi, ovvero di data center, infrastruttura, piattaforma,
applicazione o carico di lavoro.
ο·
Fonti di analisi. Base di riferimento e cronologia recente del monitoraggio, avvisi del sistema, registri
eventi e query diagnostiche devono essere tempestivamente accessibili dalle parti pertinenti.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
4
ο·
Coordinamento delle dipendenze. Individuare le dipendenze aziendali e del sistema nello stack
applicativo e tra parti interessate.
ο·
Albero delle decisioni. Un albero delle decisioni predeterminato, ripetibile e convalidato che includa
responsabilità dei ruoli, valutazione del problema, criteri di failover in termini di obiettivi RPO e RTO
e passaggi di ripristino stabiliti.
ο·
Convalida. Dopo avere eseguito le procedure di ripristino in seguito all'interruzione, individuare le
azioni da intraprendere per verificare che il sistema sia tornato al normale funzionamento.
ο·
Documentazione. Acquisire tutti gli elementi di cui sopra in una serie di documenti, con un livello di
dettaglio e chiarezza che permetta a un team terzo di eseguire il piano di ripristino con assistenza
minima. Questo tipo di documentazione è detto anche “runbook” o ”guida di riferimento dettagliata”.
ο·
Prove di ripristino. Eseguire regolarmente il piano di ripristino di emergenza per definire le
aspettative di base per gli obiettivi RTO e valutare se ruotare periodicamente l'hosting del sito di
produzione primario dal sito primario e ognuno dei siti di ripristino di emergenza.
Panoramica: disponibilità elevata con Microsoft SQL Server 2012
La realizzazione degli obiettivi RPO e RTO prefissati richiede un tempo di attività continuo per le
applicazioni critiche e la protezione dei dati strategici durante il tempo di inattività pianificato e non
pianificato. SQL Server offre un set di caratteristiche e funzionalità in grado di realizzare questi obiettivi,
contenendo al contempo costi e complessità.
I lettori già esperti delle nuove funzionalità AlwaysOn possono passare direttamente alla trattazione
dettagliata nella sezione Livelli di protezione di SQL Server AlwaysOn di questo documento.
SQL Server AlwaysOn
AlwaysOn è una nuova soluzione integrata, flessibile e conveniente per la disponibilità elevata e il
ripristino di emergenza. Può fornire ridondanza hardware e dei dati tra data center e al loro interno
e migliora il tempo di failover delle applicazioni per aumentare la disponibilità delle applicazioni di
importanza strategica. AlwaysOn assicura flessibilità di configurazione e il riutilizzo degli investimenti
hardware effettuati.
Con una soluzione AlwaysOn è possibile usufruire di due principali funzionalità di SQL Server 2012 per la
configurazione della disponibilità a livello di database e a livello di istanza:
ο·
Gruppi di disponibilità AlwaysOn, una novità di SQL Server 2012, potenzia in modo notevole il
mirroring del database e favorisce la disponibilità dei database dell'applicazione, eliminando inoltre
il rischio di perdita dei dati proteggendoli attraverso lo spostamento basato su log, senza dischi condivisi.
I gruppi di disponibilità forniscono un set integrato di opzioni che includono il failover automatico
e manuale di un gruppo logico di database, il supporto di un massimo di quattro repliche
secondarie, il failover veloce dell'applicazione e la correzione automatica della pagina.
ο·
Le istanze del cluster di failover AlwaysOn migliorano la funzionalità di clustering di failover di SQL
Server e supportano il clustering multisito tra subnet, che permette il failover delle istanze di SQL
Server tra data center. Un altro vantaggio fondamentale è costituito dal failover più veloce e prevedibile
delle istanze, per un ripristino più rapido delle applicazioni.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
5
Riduzione significativa del tempo di inattività pianificato
La causa principale del tempo di inattività delle applicazioni in qualsiasi organizzazione è riconducibile ad
attività pianificate, quali l'applicazione di patch al sistema operativo, la manutenzione dell'hardware
e così via. Queste attività possono coprire quasi l'80% delle interruzioni in un ambiente IT.
SQL Server 2012 favorisce una notevole diminuzione del tempo di inattività pianificato riducendo
i requisiti di applicazione di patch e consentendo un numero maggiore di operazioni di manutenzione
online, come illustrato di seguito.
ο·
Windows Server Core. SQL Server 2012 supporta le distribuzioni su Windows Server Core,
un'opzione di distribuzione minima e semplificata per Windows Server 2008 e Windows Server 2008
R2. Questa configurazione del sistema operativo può garantire un minor tempo di inattività
pianificato riducendo di ben il 60% i requisiti di applicazione di patch al sistema operativo.
ο·
Operazioni online. Il supporto migliorato per le operazioni online, come la reindicizzazione delle
applicazioni LOB e l'aggiunta di colonne con valori predefiniti, favorisce la riduzione del tempo di
inattività durante le operazioni di manutenzione dei database.
ο·
Aggiornamento in sequenza e applicazione di patch. Le funzionalità AlwaysOn facilitano gli
aggiornamenti in sequenza e l'applicazione di patch alle istanze, favorendo notevolmente la
riduzione del tempo di inattività delle applicazioni.
ο·
SQL Server su Hyper-V. Le istanze di SQL Server ospitate nell'ambiente Hyper-V godono dell'ulteriore
vantaggio di Live Migration, che consente di eseguire la migrazione delle macchine virtuali tra host
senza alcun tempo di inattività. Gli amministratori possono eseguire operazioni di manutenzione
sull'host senza impatto sulle applicazioni.
Eliminazione di hardware inattivo e miglioramento dell'efficienza dei costi e delle prestazioni
Le soluzioni tipiche per la disponibilità elevata comportano la distribuzione di costosi server passivi
e ridondanti. Gruppi di disponibilità AlwaysOn consente di utilizzare repliche di database secondarie su
server altrimenti passivi o inattivi per carichi di lavoro di sola lettura, come query di report di SQL Server
Reporting Services o operazioni di backup. La possibilità di utilizzare simultaneamente le repliche di
database primarie e secondarie favorisce il miglioramento delle prestazioni di tutti i carichi di lavoro
grazie a un miglior bilanciamento delle risorse tra gli investimenti hardware per i server.
Facilità di distribuzione e gestione
Caratteristiche come la Configurazione guidata, il supporto per l'interfaccia della riga di comando di
Windows PowerShell, i dashboard, le DMV, la gestione basata su criteri e l'integrazione con System
Center contribuiscono a semplificare e distribuire la gestione dei gruppi di disponibilità.
Funzionalità RPO e RTO a confronto
Gli obiettivi aziendali per RPO (obiettivo del punto di recupero) e RTO (obiettivo del tempo di recupero)
devono costituire i principi guida chiave nel selezionare una tecnologia SQL Server alla base della
soluzione per la disponibilità elevata e il ripristino di emergenza. Nella tabella viene presentato un
confronto sommario tra i tipi di risultati ottenibili con le diverse soluzioni.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
6
Soluzione SQL Server per la disponibilità
elevata e il ripristino di emergenza
Potenziale
perdita di
dati (RPO)
Potenziale
tempo di
recupero
(RTO)
Failover
automatico
Repliche
secondarie
leggibili(1)
Gruppo di disponibilità AlwaysOn - Commit sincrono
Zero
Secondi
Sì(4)
0-2
Gruppo di disponibilità AlwaysOn - Commit asincrono
Secondi
Minuti
No
0-4
Istanza del cluster di failover AlwaysOn
ND(5)
Sì
ND
Mirroring del database(2) - Sicurezza elevata
(sincrono + server di controllo)
Zero
Da secondi
a minuti
Secondi
Sì
ND
Mirroring del database(2) - Prestazioni elevate
(asincrono)
Secondi(6)
Minuti(6)
No
ND
Log shipping
Minuti(6)
Da minuti
a ore(6)
Da ore
a giorni(6)
No
Non durante
un ripristino
Non durante
un ripristino
Backup, copia, ripristino(3)
(1) Il
Ore(6)
No
gruppo di disponibilità AlwaysOn non può avere più di quattro repliche secondarie totali, indipendentemente dal tipo.
(2) Questa
funzionalità verrà rimossa in una versione successiva di Microsoft SQL Server. Utilizzare Gruppi di disponibilità AlwaysOn.
(3) Backup,
copia e ripristino sono adatti per il ripristino di emergenza, ma non per la disponibilità elevata.
(4)
Non è supportato il failover automatico di un gruppo di disponibilità verso o da un'istanza del cluster di failover.
(5)
L'istanza del cluster di failover non fornisce in sé protezione dati; la perdita dei dati dipende dall'implementazione del sistema di archiviazione.
(6)
Dipende strettamente dal carico di lavoro, dal volume dei dati e dalle procedure di failover.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
7
Livelli di protezione di SQL Server AlwaysOn
Le soluzioni SQL Server AlwaysOn forniscono le funzionalità di tolleranza di errore e ripristino di emergenza
a diversi livelli logici e fisici dei componenti dell'infrastruttura e delle applicazioni. È da sempre pratica
comune attuare una separazione di compiti e responsabilità per i vari gruppi di destinatari e ruoli interessati,
in modo che ciascuno si occupasse soprattutto di una parte di tali livelli delle soluzioni.
Questa sezione è organizzata in modo da descrivere dettagliatamente ciascuno dei livelli e fornire
i fondamenti logici e le indicazioni per definire la progettazione e l'implementazione della soluzione più
adeguata alle diverse esigenze.
Ai fini di una soluzione SQL Server AlwaysOn efficace sono necessarie una buona comprensione dei livelli
seguenti e l'implementazione di una collaborazione tra livelli.
ο·
Livello infrastruttura. La tolleranza di errore a livello di server e la comunicazione di rete tra nodi
sfruttano le funzionalità Windows Server Failover Clustering (WSFC) per il monitoraggio dell'integrità
e il coordinamento del failover.
ο·
Livello istanza di SQL Server. Un'istanza del cluster di failover di SQL Server AlwaysOn è un'istanza di
SQL Server installata in più nodi server in un cluster WSFC, sui quali può eseguire il failover. I nodi
che ospitano l'istanza sono collegati a un sistema di archiviazione condiviso, simmetrico e affidabile
(rete SAN o SMB).
ο·
Livello database. Un gruppo di disponibilità è un set di database utente di cui viene eseguito
simultaneamente il failover. Un gruppo di disponibilità è costituito da una replica primaria e da una
a quattro repliche secondarie. Ogni replica è ospitata da un'istanza di SQL Server (del cluster di
failover o meno) su un nodo diverso del cluster WSFC.
ο·
Connettività client. Le applicazioni client di database possono connettersi direttamente a un nome
di rete dell'istanza di SQL Server oppure a un nome di rete virtuale (VNN) associato a un listener del
gruppo di disponibilità. Il VNN separa la topologia del cluster WSFC e del gruppo di disponibilità,
reindirizzando a livello logico le richieste di connessione all'istanza di SQL Server e alla replica di
database appropriate.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
8
La topologia logica di una tipica soluzione AlwaysOn viene illustrata nel diagramma seguente:
Disponibilità dell'infrastruttura
Sia i gruppi di disponibilità AlwaysOn che le istanze del cluster di failover AlwaysOn utilizzano il sistema
operativo Windows Server e WSFC come tecnologia di piattaforma. È più che mai importante che gli
amministratori di database di Microsoft SQL Server abbiano acquisito una solida comprensione di tali
tecnologie.
Sistema operativo Windows
SQL Server è basato sulla piattaforma Windows per l'infrastruttura e i servizi fondamentali di rete,
archiviazione, sicurezza, applicazione di patch e monitoraggio, con una progressiva corrispondenza tra le
differenti edizioni di SQL Server 2012 e le più ampie funzionalità e capacità delle edizioni simili del
sistema operativo Windows Server 2008 R2, come Windows Server 2008 R2 Standard, Windows Server
2008 R2 Enterprise e Windows Server 2008 R2 Datacenter.
Per ulteriori informazioni, vedere Requisiti hardware e software per l'installazione di SQL Server 2012
(http://msdn.microsoft.com/it-it/library/ms143506(SQL.110).aspx).
Opzione di installazione Windows Server Core
Una funzionalità chiave di SQL Server 2012 per la disponibilità elevata è la distribuzione nell'opzione di
installazione Windows Server Core in Windows Server 2008 o versioni successive. L'opzione di
installazione Server Core fornisce un ambiente minimo per l'esecuzione di determinati ruoli server con
funzionalità limitata e supporto molto ridotto per applicazioni con GUI. Per impostazione predefinita
sono abilitati solo i servizi necessari e un ambiente di prompt dei comandi.
Questa modalità operativa limita la superficie d'attacco del sistema operativo e l'overhead di sistema
e può ridurre significativamente i requisiti di normale manutenzione, assistenza e applicazione di patch.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
9
Una considerazione importante per la distribuzione di SQL Server 2012 su Windows Server Core è che
tutte le attività di distribuzione, configurazione, amministrazione e manutenzione di SQL Server e del
sistema operativo devono essere completate utilizzando un ambiente di scripting come Windows
PowerShell, la riga di comando o strumenti remoti.
Ottimizzazione di SQL Server per il cloud privato
Gli scenari di disponibilità elevata e ripristino di emergenza assumono un ruolo sempre più strategico
nell'ambiente cloud privato. La distribuzione di SQL Server nel cloud privato favorisce l'uso efficiente
delle risorse di elaborazione, di rete e di archiviazione, riducendo sia l'impatto fisico che i costi in conto
capitale e di esercizio. Facilita inoltre il consolidamento delle distribuzioni, il ridimensionamento
efficiente delle risorse e la loro distribuzione su richiesta senza pregiudicare le funzioni di controllo.
Oltre a Windows Server Failover Clustering per i sistemi Hyper-V sia host che guest, SQL Server supporta
anche Live Migration, che consente di spostare macchine virtuali tra host con un tempo di inattività
irrilevante. Live Migration è utilizzabile anche in combinazione con il clustering guest.
Per ulteriori informazioni, vedere Private Cloud Computing - Optimizing SQL Server for Private Cloud
(http://www.microsoft.com/SqlServerPrivateCloud).
Windows Server Failover Clustering
Windows Server Failover Clustering (WSFC) offre caratteristiche di infrastruttura che supportano gli
scenari di disponibilità elevata e ripristino di emergenza delle applicazioni server ospitate, come
Microsoft SQL Server.
Se si verifica un errore in un nodo o un servizio del cluster WSFC, le risorse o i servizi ospitati su tale
nodo possono essere trasferiti automaticamente o manualmente a un altro nodo disponibile, con un
processo noto come failover. Con le soluzioni AlwaysOn questo processo è valido sia per le istanze del
cluster di failover che per i gruppi di disponibilità.
I nodi del cluster WSFC operano insieme per fornire collettivamente i tipi di funzionalità seguenti:
ο·
Notifiche e metadati distribuiti. I metadati del servizio WSFC e delle applicazioni ospitate vengono
gestiti in ogni nodo del cluster. I metadati includono la configurazione e lo stato di WSFC oltre alle
impostazioni delle applicazioni ospitate. Le modifiche apportate ai metadati o allo stato su un nodo
vengono automaticamente propagate agli altri nodi del cluster.
ο·
Gestione delle risorse. I singoli nodi del cluster possono fornire risorse fisiche, ad esempio archiviazione
a collegamento diretto (DAS), interfacce di rete e accesso all'archiviazione su dischi condivisi. Le
applicazioni ospitate, come SQL Server, effettuano la registrazione come risorse cluster e possono
configurare dipendenze di avvio e integrità da altre risorse.
ο·
Monitoraggio dell'integrità. Il rilevamento dell'integrità del nodo primario e tra nodi viene effettuato
combinando comunicazioni di rete di tipo heartbeat e monitoraggio delle risorse. Lo stato
complessivo del cluster è determinato dai voti di un quorum di nodi nel cluster.
ο·
Coordinamento del failover. Ogni risorsa è configurata per essere ospitata su un nodo primario
e può essere trasferita automaticamente o manualmente a uno o più nodi secondari. I criteri di
failover basati sull'integrità controllano il trasferimento automatico della proprietà della risorsa tra
i nodi. Quando avviene il failover, viene inviata una notifica ai nodi e alle applicazioni ospitate
perché possano reagire nel modo appropriato.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
10
Per ulteriori informazioni, vedere le pagine di Windows Server | Clustering di failover e bilanciamento
dei nodi (http://www.microsoft.com/windowsserver2008/it/it/failover-clustering-main.aspx).
Nota: è ora essenziale che gli amministratori di database comprendano i meccanismi interni dei cluster
WSFC e della gestione del quorum. Tutte le procedure AlwaysOn, dal monitoraggio dell'integrità alla
gestione e al ripristino in seguito a un errore, sono intrinsecamente legate alla configurazione WSFC
utilizzata.
Configurazioni di archiviazione WSFC
Windows Server Failover Clustering si basa su ogni nodo nel cluster per gestire i dispositivi di
archiviazione, i volumi dei dischi e il file system connessi. Il presupposto del funzionamento di WSFC
è che il sottosistema di archiviazione sia estremamente affidabile e di conseguenza, se il dispositivo di
archiviazione collegato a un nodo non è disponibile, il nodo del cluster viene considerato in errore.
Per le operazioni basate su scrittura, il volume di un disco è collegato a livello logico a un solo nodo del
cluster per volta tramite una prenotazione permanente SCSI-3. In base alle funzionalità e alla configurazione
del sottosistema di archiviazione, se un nodo non funziona la proprietà logica del volume del disco può
essere trasferita a un altro nodo nel cluster.
Le soluzioni SQL Server AlwaysOn sfruttano una serie limitata di combinazioni di configurazione delle
risorse di archiviazione WSFC, tra cui:
ο·
Dispositivi collegati direttamente e dispositivi remoti. I dispositivi di archiviazione sono collegati
direttamente e fisicamente al server o vengono presentati da un dispositivo remoto tramite una
scheda di rete o una scheda bus host (HBA). Le tecnologie di archiviazione remota includono
soluzioni basate su rete SAN (rete di archiviazione virtuale), come iSCSI o Fibre Channel, e soluzioni
basate su condivisioni di file SMB (Server Message Block).
ο·
Dispositivi simmetrici e dispositivi asimmetrici. I dispositivi di archiviazione vengono considerati
simmetrici se a ciascun nodo vengono presentati esattamente la stessa configurazione dei volumi
dei dischi logici e gli stessi percorsi di file. L'implementazione fisica e la capacità dei volumi dei dischi
sottostanti possono variare.
ο·
Archiviazione dedicata e archiviazione condivisa. Le risorse di archiviazione dedicata sono riservate
all'utilizzo di un solo nodo nel cluster a cui vengono assegnate, mentre le risorse di archiviazione
condivisa sono accessibili a più nodi nel cluster. Il controllo e la proprietà di dispositivi di archiviazione
condivisa conformi possono essere trasferiti da un nodo all'altro tramite protocolli SCSI-3. WSFC
supporta l'hosting multinodo simultaneo di volumi condivisi del cluster per scopi di condivisione di
file, ma SQL Server non supporta l'accesso multinodo simultaneo a un volume condiviso.
Nota: per l'accesso alle istanze del cluster di failover di SQL Server da parte di tutti i possibili proprietari
dei nodi delle istanze è comunque necessaria l'archiviazione condivisa simmetrica. Tuttavia, con
l'introduzione di Gruppi di disponibilità AlwaysOn, è ora possibile distribuire diverse istanze non di
cluster di failover di SQL Server in un cluster WSFC, ognuna con le proprie risorse di archiviazione
univoche dedicate, locali o remote.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
11
Rilevamento dell'integrità e failover delle risorse WSFC
Ogni risorsa in un nodo del cluster WSFC può segnalare il proprio stato e la propria integrità,
periodicamente o su richiesta. Varie sono le circostanze che possono indicare l'errore di una risorsa
cluster, ad esempio un'interruzione dell'alimentazione, errori del disco o di memoria, errori nella
comunicazione di rete, configurazioni errate o servizi che non rispondono.
È possibile rendere dipendenti l'una dall'altra risorse cluster WSFC quali reti, archiviazione o servizi.
L'integrità cumulativa di una risorsa è determinata dal rollup successivo della sua integrità con quella di
ognuna delle sue dipendenze.
Per Gruppi di disponibilità AlwaysOn, il gruppo di disponibilità e il listener del gruppo di disponibilità
sono registrati come risorse cluster WSFC. Per le istanze del cluster di failover AlwaysOn, il servizio SQL
Server e il servizio SQL Server Agent vengono registrati come risorse cluster WSFC ed entrambi vengono
resi dipendenti dalla risorsa nome di rete virtuale dell'istanza.
Se in una risorsa cluster WSFC si verifica un dato numero di errori o guasti in un determinato periodo di
tempo, il servizio cluster eseguirà una delle azioni seguenti in base ai criteri di failover configurati.
ο·
ο·
ο·
Riavvio della risorsa sul nodo corrente.
Impostazione offline della risorsa.
Avvio di un failover automatico della risorsa e delle dipendenze su un altro nodo.
Nota: il rilevamento dell'integrità delle risorse cluster WSFC non ha impatto diretto sull'integrità dei
singoli nodi o su quella complessiva del cluster.
Procedura guidata di convalida cluster WSFC
La procedura guidata di convalida cluster è una funzionalità integrata nel clustering di failover in
Windows Server 2008 e Windows Server 2008 R2. Si tratta di un utilissimo strumento di cui può servirsi
l'amministratore del database per verificare l'esistenza di un ambiente WSFC stabile, pulito e integro
prima di distribuire una soluzione SQL Server AlwaysOn.
Questa procedura guidata consente di eseguire un set di test specifici su un insieme di server da
utilizzare come nodi in un cluster oppure su un cluster esistente. Questo processo consente di testare,
direttamente e singolarmente, l'hardware e il software dei server per ottenere una valutazione accurata
dell'adeguatezza di una data configurazione per un cluster WSFC.
Questo processo di convalida è costituito da una serie di test e raccolte di dati su ogni nodo nelle
categorie seguenti:
ο·
Inventario. Informazioni sulle versioni del BIOS, i livelli di ambiente, le schede bus host, la RAM, le
versioni del sistema operativo, i dispositivi, i servizi, i driver e così via.
ο·
Rete. Informazioni sull'ordine di associazione delle NIC, le comunicazioni di rete, la configurazione
degli indirizzi IP e del firewall. Vengono convalidate le comunicazioni tra nodi su tutte le NIC.
ο·
Archiviazione. Informazioni sui dischi, la capacità delle unità, la latenza di accesso, i file system e così
via. Vengono convalidati i comandi SCSI, la funzionalità di failover dei dischi e la configurazione
dell'archiviazione simmetrica o asimmetrica.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
12
ο·
Configurazione di sistema. Vengono convalidati la configurazione di Active Directory, l'avvenuta
firma dei driver, le impostazioni del dump di memoria, le funzionalità e i servizi del sistema
necessari, l'architettura di processore compatibile e i livelli dei Service Pack e dell'aggiornamento del
software Windows.
I risultati di questi test di convalida forniscono le informazioni necessarie per ottimizzare la
configurazione di un cluster, tenere traccia della configurazione e individuare potenziali problemi di
configurazione prima che provochino inattività. È possibile salvare un report dei risultati dei test sotto
forma di documento HTML da consultare in futuro.
I test devono essere eseguiti prima e dopo avere apportato modifiche alla configurazione di WSFC,
prima di installare SQL Server e come parte di qualsiasi processo di ripristino di emergenza. Un report di
convalida del cluster è richiesto dal Servizio Supporto Tecnico Clienti Microsoft come condizione per la
fornitura del supporto Microsoft a una specifica configurazione cluster WSFC.
Per ulteriori informazioni, vedere Guida dettagliata ai cluster di failover: Convalidare l'hardware per un
cluster di failover (http://technet.microsoft.com/it-it/library/cc732035 (WS.10).aspx).
Nota: se la configurazione del cluster prevede l'archiviazione asimmetrica, come nel caso delle soluzioni
di archiviazione di tipo geo-clustering basate sull'hardware o nel caso di Gruppi di disponibilità
AlwaysOn, potrebbe essere necessario applicare una serie di hotfix per evitare errori della procedura
guidata durante la convalida dell'archiviazione.
Per ulteriori informazioni, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn
(SQL Server) (http://msdn.microsoft.com/it-it/library/ff878487(SQL.110).aspx#SystemReqsForAOAG).
Modalità di quorum e configurazione del voto nel WSFC
WSFC utilizza un approccio basato sul quorum per monitorare l'integrità complessiva del cluster
e ottimizzare la tolleranza di errore a livello di nodo. Una comprensione di base delle modalità di
quorum e della configurazione di voto dei nodi di WSFC è molto importante per progettare ed eseguire
una soluzione AlwaysOn per la disponibilità elevata e il ripristino di emergenza, nonché per risolverne
i problemi.
Rilevamento dell'integrità del cluster in base al quorum
Ogni nodo in un cluster WSFC partecipa alla comunicazione heartbeat periodica per condividere il
proprio stato di integrità con gli altri nodi. I nodi che non rispondono sono considerati in stato di errore.
Un set di nodi quorum rappresenta una maggioranza dei nodi votanti e degli elementi di controllo nel
cluster WSFC. L'integrità e lo stato complessivi di un cluster WSFC sono determinati da un voto di
quorum periodico. La presenza di un quorum indica che il cluster è sufficientemente integro da fornire
tolleranza di errore a livello di nodo.
L'assenza di un quorum indica che il cluster non è integro. L'integrità complessiva del cluster WSFC
è necessaria per garantire la disponibilità di nodi secondari integri in cui eseguire il failover dei nodi
primari. Se il voto del quorum dà esito negativo, l'intero cluster WSFC viene impostato offline come
misura precauzionale, che implica anche l'arresto di tutte le istanze di SQL Server registrate con il
cluster.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
13
Nota: se un cluster WSFC viene impostato offline a causa di un errore del quorum, è necessario
l'intervento manuale per riportarlo online. Per ulteriori informazioni, vedere la sezione Ripristino di
emergenza del cluster WSFC tramite quorum forzato più avanti in questo documento.
Modalità di quorum
Per specificare la metodologia utilizzata per i voti del quorum viene configurata una modalità di quorum
a livello del cluster WSFC. In base al numero di nodi nel cluster l'utilità Gestione cluster di failover
consiglia una modalità di quorum.
Il quorum di voti viene determinato da una delle modalità di quorum riportate di seguito.
ο·
Maggioranza dei nodi. Oltre la metà dei nodi votanti nel cluster deve votare affermativamente
perché il cluster sia ritenuto integro.
ο·
Maggioranza dei nodi e delle condivisioni file. È simile alla modalità di quorum Maggioranza dei
nodi, ad eccezione del fatto che viene configurata anche una condivisione file remota come
elemento di controllo del voto e la connettività da qualsiasi nodo a tale condivisione viene anch'essa
conteggiata come voto affermativo. Oltre la metà dei possibili voti deve essere affermativa perché il
cluster sia ritenuto integro.
Come procedura consigliata, la condivisione file di controllo non deve trovarsi in alcun nodo nel
cluster e deve essere visibile a tutti i nodi nel cluster.
ο·
Maggioranza dei nodi e dei dischi. È simile alla modalità di quorum Maggioranza dei nodi, ad
eccezione del fatto che viene designata come elemento di controllo di voto anche una risorsa cluster
di tipo disco condiviso e la connettività da qualsiasi nodo a tale disco condiviso viene anch'essa
conteggiata come voto affermativo. Oltre la metà dei possibili voti deve essere affermativa perché il
cluster sia ritenuto integro.
ο·
Solo disco. Viene designata come elemento di controllo anche una risorsa cluster di tipo disco
condiviso e la connettività da qualsiasi nodo a tale disco condiviso viene anch'essa conteggiata come
voto affermativo.
Per ulteriori informazioni, vedere Guida dettagliata ai cluster di failover: Configurazione del quorum in
un cluster (http://technet.microsoft.com/it-it/library/cc770620(WS.10).aspx).
Nota: a meno che ogni nodo nel cluster non sia configurato per l'utilizzo dello stesso disco di controllo
del quorum di archiviazione condivisa, è in genere preferibile utilizzare la modalità di quorum
Maggioranza dei nodi se è presente un numero dispari di nodi votanti, mentre la modalità Maggioranza
dei nodi e delle condivisioni file è più appropriata in presenza di un numero pari di nodi votanti.
Nodi votanti e non votanti
Per impostazione predefinita, ogni nodo nel cluster WSFC è incluso come membro del quorum del
cluster. Ogni nodo, condivisione file di controllo e disco di controllo ha a disposizione un solo voto per
determinare l'integrità complessiva del cluster. Nell'illustrare il quorum fino a questo punto, il set di nodi
del cluster WSFC che votano per determinare l'integrità del cluster è stato definito set di nodi votanti. In
alcune circostanze è però preferibile evitare che ogni nodo abbia un voto.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
14
Ogni nodo in un cluster WSFC tenta continuamente di stabilire un quorum. Un singolo nodo nel cluster
non può determinare in modo definitivo se il cluster sia complessivamente integro o non integro. In
qualsiasi momento specificato, dal punto di vista di ciascun nodo, alcuni degli altri nodi possono apparire
come offline, con un failover in corso oppure possono non rispondere a causa di un errore di comunicazione
di rete. Una funzione principale del voto del quorum consiste nel determinare se lo stato apparente di
ogni nodo nel cluster WSFC corrisponda in realtà all'effettivo stato di tali nodi.
Per tutti i modelli di quorum ad eccezione di Solo disco, l'efficacia di un voto del quorum dipende da
comunicazioni affidabili tra tutti i nodi votanti nel cluster. Il voto del quorum deve essere considerato
attendibile quando tutti i nodi sono sulla stessa subnet fisica.
Se, tuttavia, si riscontra che un nodo in un'altra subnet non risponde in un voto del quorum, ma è in
realtà online e altrimenti integro, la causa è molto probabilmente dovuta a un errore di comunicazione
di rete tra subnet. A seconda della topologia del cluster, della modalità di quorum e della configurazione
dei criteri di failover, l'errore di comunicazione di rete potrebbe effettivamente implicare la creazione di
più di un set (o subset) di nodi votanti.
Se più di un subset di nodi votanti è in grado di stabilire singolarmente un quorum, si verifica uno
scenario split brain, in cui i nodi nei quorum separati possono comportarsi in modo diverso ed essere in
conflitto gli uni con gli altri.
Nota: lo scenario split brain è possibile solo se un amministratore di sistema esegue manualmente
un'operazione di quorum forzato o, in casi molto rari, un failover manuale forzato, suddividendo in
modo esplicito il set di nodi del quorum. Per ulteriori informazioni, vedere la sezione Ripristino di
emergenza del cluster WSFC tramite quorum forzato più avanti in questo documento.
Per semplificare la configurazione del quorum e aumentare il tempo di attività, è possibile modificare
l'impostazione NodeWeight (un valore 0 o 1) di ogni nodo per impedire che il voto del nodo venga
conteggiato rispetto al quorum.
Modifiche consigliate ai voti del quorum
Per determinare la configurazione consigliata per i voti del quorum del cluster, applicare in sequenza le
linee guida seguenti.
1. Nessun voto per impostazione predefinita. Presupporre che ogni nodo non debba votare senza
giustificazione esplicita.
2. Includere tutti i nodi primari. Ogni nodo che ospita una replica primaria del gruppo di disponibilità
AlwaysOn o è il proprietario preferito dell'istanza del cluster di failover AlwaysOn deve disporre di
un voto.
3. Includere i possibili proprietari del failover automatico. Ogni nodo che può ospitare una replica
primaria o un'istanza del cluster di failover, come risultato di un failover automatico, deve disporre
di un voto.
4. Escludere nodi del sito secondari. In generale, non assegnare voti a nodi che si trovano in un sito di
ripristino di emergenza secondario. Non è consigliabile fare in modo che i nodi nel sito secondario
contribuiscano a una decisione che comporti l'impostazione offline del cluster quando non vi sono
problemi con il sito primario.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
15
5. Numero dispari di voti. Se necessario, aggiungere una condivisione file di controllo, un nodo di
controllo (con o senza istanza di SQL Server) o un disco di controllo al cluster e modificare la
modalità di quorum per impedire possibili pareggi nel voto del quorum.
6. Valutare nuovamente le assegnazioni dei voti dopo il failover. Non è consigliabile eseguire il
failover in una configurazione del cluster che non supporta un quorum integro.
Per ulteriori informazioni sulla modifica dei voti dei nodi, vedere Configurare le impostazioni NodeWeight
per il quorum del cluster (http://msdn.microsoft.com/it-it/library/hh270281(SQL.110).aspx).
Non è possibile modificare il voto di una condivisione file di controllo. È necessario invece selezionare
una modalità di quorum diversa per includere o escludere il voto.
Nota: in SQL Server vengono esposte diverse DMV di sistema che semplificano l'amministrazione delle
impostazioni correlate alla configurazione del cluster WSFC e ai voti del quorum dei nodi.
Per ulteriori informazioni, vedere Monitorare Gruppi di disponibilità (Transact-SQL)
(http://msdn.microsoft.com/it-it/library/ff878305(SQL.110).aspx).
Ripristino di emergenza del cluster WSFC tramite quorum forzato
Un errore del quorum è causato generalmente da una situazione di emergenza a livello di sistema o da
un errore di comunicazione persistente che interessa diversi nodi del cluster WSFC. Tenere presente che
l'errore del quorum provoca l'impostazione offline di tutti i servizi del cluster, le istanze di SQL Server
e I gruppi di disponibilità del cluster WSFC, in quanto il cluster non è in grado di garantire la tolleranza di
errore a livello di nodo. Un errore del quorum significa che i nodi votanti integri del cluster WSFC non
soddisfano più il modello di quorum. È possibile che alcuni nodi abbiano avuto esito completamente
negativo e alcuni abbiano solo arrestato il servizio WSFC e siano altrimenti integri, a eccezione della
perdita della capacità di comunicare con un quorum.
Per riportare online il cluster WSFC, è necessario correggere la causa principale dell'errore del quorum
su almeno un nodo nella configurazione esistente. In uno scenario di emergenza può essere necessario
riconfigurare l'hardware o utilizzarne di nuovo. Può inoltre rivelarsi opportuno riconfigurare i nodi
restanti nel cluster WSFC in base alla topologia del cluster rimasto attivo.
È possibile utilizzare la procedura di quorum forzato su un nodo del cluster WSFC per ignorare i controlli
di sicurezza che hanno portato il cluster offline. L'esecuzione della procedura comporta la sospensione
dei controlli di voto del quorum all'interno del cluster e consente di riportare online le risorse del cluster
WSFC e SQL Server su tutti i nodi nel cluster.
È opportuno che questo tipo di processo di ripristino di emergenza includa i passaggi seguenti:
1) Determinare l'ambito dell'errore. Determinare i gruppi di disponibilità o le istanze di SQL Server che
non rispondono, i nodi del cluster online e disponibili per l'uso dopo la condizione di emergenza
e quindi esaminare i registri eventi di Windows e i log di sistema di SQL Server. Dove possibile,
è consigliabile mantenere dati e registri di sistema per un'analisi successiva.
2) Avviare il cluster WSFC tramite quorum forzato su un singolo nodo. Su un nodo altrimenti integro,
riportare manualmente il cluster online utilizzando la procedura di quorum forzato. Per ridurre al
minimo la possibile perdita di dati, selezionare un nodo che nell'ultima operazione ospitava una
replica primaria del gruppo di disponibilità.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
16
Per ulteriori informazioni, vedere Forzare l'avvio di un cluster WSFC senza un quorum
(http://msdn.microsoft.com/it-it/library/hh270275(v=SQL.110).aspx).
Nota: l'impostazione del quorum forzato implica il blocco dei controlli del quorum a livello di cluster
finché il cluster WSFC non ottiene una maggioranza di voti e passa automaticamente alla modalità
operativa di quorum normale.
3) Avviare il servizio WSFC normalmente su tutti i nodi diversamente integri, uno alla volta. Non
è necessario specificare l'opzione per il quorum forzato quando si avvia il servizio cluster sugli altri
nodi.
Man mano che il servizio WSFC ritorna online su ogni nodo, viene avviata la negoziazione con gli altri
nodi integri per sincronizzare il nuovo stato di configurazione del cluster. Questa operazione deve
essere effettuata un nodo per volta per evitare possibili casi di race condition nella risoluzione
dell'ultimo stato noto del cluster.
Nota: assicurarsi che ogni nodo avviato possa comunicare con gli altri nodi da poco online. In caso
contrario, vi è il rischio di creare più set di nodi del quorum e quindi uno scenario split brain. Se
i risultati nel passaggio 1 sono accurati, questa situazione non dovrebbe verificarsi.
4) Applicare la nuova modalità di quorum e la nuova configurazione di voto dei nodi. Se tramite la
procedura di quorum forzato vengono riavviati tutti i nodi del cluster e la causa principale dell'errore
del quorum è stata corretta, non è necessario apportare modifiche alla modalità di quorum e alla
configurazione di voto dei nodi originali.
In caso contrario, è necessario valutare il nodo del cluster appena ripristinato e la topologia della
replica di disponibilità e modificare la modalità di quorum e le assegnazioni dei voti per ogni nodo
nel modo appropriato. Impostare offline il servizio cluster WSFC sui nodi non ripristinati
o impostarne su zero i voti.
Nota: a questo punto è possibile che i nodi e le istanze di SQL Server nel cluster risultino
apparentemente di nuovo funzionanti. In realtà è possibile che non sia ancora presente un quorum
integro. Utilizzando Gestione cluster di failover o il dashboard AlwaysOn all'interno di SQL Server
Management Studio (o le DMV appropriate), verificare che sia stato ripristinato un quorum integro.
5) Ripristinare le repliche di database del gruppo di disponibilità nel modo necessario. Alcuni
database potrebbero procedere al ripristino e ritornare online autonomamente come parte del
normale processo di avvio di SQL Server, mentre il ripristino di altri database potrebbe richiedere
passaggi manuali aggiuntivi.
È possibile ridurre al minimo l'eventuale perdita di dati e il tempo di recupero per le repliche del
gruppo di disponibilità riportandole online in questa sequenza, se fattibile: replica primaria, repliche
secondarie sincrone, repliche secondarie asincrone.
6) Ripristinare o sostituire componenti con errori e convalidare di nuovo il cluster. Dopo aver
eseguito il ripristino in seguito alla situazione di emergenza iniziale e dell'errore del quorum,
è necessario ripristinare o sostituire i nodi con errori e modificare di conseguenza le configurazioni
di WSFC e AlwaysOn correlate. Questa operazione può implicare l'eliminazione di repliche del
gruppo di disponibilità, la rimozione di nodi dal cluster o l'eliminazione e la reinstallazione del
software in un nodo.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
17
Nota: è necessario ripristinare o rimuovere tutte le repliche di disponibilità con errori. In SQL Server
2012 il log delle transazioni non viene troncato oltre l'ultimo punto noto della replica di disponibilità
meno aggiornata. Se una replica con errori non viene ripristinata o rimossa dal gruppo di disponibilità,
le dimensioni dei log delle transazioni aumenteranno e si correrà il rischio di esaurire lo spazio dei
log delle transazioni delle altre repliche.
7) Ripetere il passaggio 4 nel modo necessario. L'obiettivo è ristabilire il livello appropriato di
tolleranza di errore e disponibilità elevata per assicurare operazioni integre.
8) Eseguire un'analisi RPO/RTO. È consigliabile analizzare i log di sistema di SQL Server, i timestamp
del database e i registri eventi di Windows per determinare la causa principale dell'errore
e documentare il punto di recupero e il tempo di recupero effettivi.
Protezione a livello di istanza di SQL Server
Il successivo livello di protezione in una soluzione AlwaysOn è la piattaforma dati in sé, ovvero le
funzionalità e le caratteristiche offerte da Microsoft SQL Server 2012 e la sua integrazione con
i componenti dell'infrastruttura di Windows Server.
Miglioramenti alla disponibilità - Istanze di SQL Server
Di seguito sono descritte le nuove funzionalità a livello di istanza di SQL Server 2012 in grado di
migliorare la disponibilità sia delle istanze del cluster di failover AlwaysOn che delle istanze autonome
che ospitano Gruppi di disponibilità AlwaysOn.
Questi miglioramenti riguardano la gestione e la risoluzione dei problemi degli scenari di failover.
ο·
Criteri di failover flessibili. Nell'output della nuova stored procedure di sistema utilizzata per il
rilevamento affidabile degli errori, sp_server_diagnostics, viene impiegata la proprietà
FailureConditionLevel per specificare la gravità del problema che interessa l'istanza di SQL Server.
Specifici criteri di failover WSFC determinano l'impatto di tale valore sull'istanza di SQL Server,
variando da una tolleranza agli errori relativa fino alla sensibilità a qualsiasi errore dei componenti
interni di SQL Server.
L'attivazione del failover può essere configurata in base a uno dei livelli di errore nella gamma
disponibile, tra cui server inaccessibile, mancata risposta del server, errore critico, errore con gravità
moderata o qualsiasi errore qualificato. La proprietà FailureConditionLevel può essere utilizzata per
i criteri di failover delle istanze del cluster di failover o dei gruppi di disponibilità.
Prima di SQL Server 2012, non era prevista alcuna granularità delle condizioni di errore per
controllare il failover, che poteva essere prodotto da qualsiasi errore a livello di servizio.
Per ulteriori informazioni, vedere Criteri di failover per istanze del cluster di failover
(http://msdn.microsoft.com/it-it/library/ff878664(SQL.110).aspx).
ο·
Strumentazione e registrazione avanzate. È disponibile una serie, specifica di AlwaysOn, di viste di
configurazione di sistema, DMV, contatori delle prestazioni e una sessione di integrità Eventi estesi
che acquisisce e mostra le informazioni necessarie per la risoluzione dei problemi, l'ottimizzazione
e il monitoraggio della distribuzione AlwaysOn. Molti di questi strumenti sono esposti tramite
i nuovi facet e criteri di Gestione criteri di SQL Server.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
18
Per ulteriori informazioni, vedere Funzioni e DMV di Gruppi di disponibilità AlwaysOn (Transact-SQL)
(http://msdn.microsoft.com/it-it/library/ff877943(SQL.110).aspx) e sys.dm_os_cluster_nodes
(http://msdn.microsoft.com/it-it/library/ms187341(SQL.110).aspx).
ο·
Supporto per la condivisione file SMB. È possibile salvare i file di database in una condivisione file
remota di Windows Server 2008 o versione successiva sia per le istanze autonome che per le istanze
del cluster di failover, eliminando la necessità di una lettera di unità separata per queste ultime. Si
tratta di una buona scelta per il consolidamento delle risorse di archiviazione o per l'hosting delle
risorse di archiviazione dei file di database in un server fisico per un sistema operativo guest della
macchina virtuale. Con la configurazione corretta, le prestazioni di I/O possono avvicinarsi molto
a quelle dell'archiviazione a collegamento diretto.
Per ulteriori informazioni, vedere SQL Databases on File Shares - It's time to reconsider the scenario
(http://blogs.msdn.com/b/sqlserverstorageengine/archive/2011/10/18/sql-databases-on-fileshares-it-s-time-to-reconsider-the-scenario.aspx).
Nota: in un cluster WSFC non è possibile aggiungere una dipendenza della risorsa condivisione file
SMB al gruppo di risorse di SQL Server, ma in questo caso sono necessarie misure separate per
assicurare la disponibilità della condivisione file. Se la condivisione file diventa non disponibile, in
SQL Server viene generata un'eccezione di I/O, seguita dal passaggio alla modalità offline.
ο·
Interoperabilità del cluster WSFC con il sistema DNS. Il nome di rete virtuale (VNN) per un'istanza
del cluster di failover o un listener del gruppo di disponibilità viene registrato con il sistema DNS solo
durante la creazione del VNN o durante le modifiche alla configurazione. Tutti gli indirizzi IP virtuali,
in stato online o offline, vengono registrati con il sistema DNS sotto lo stesso nome di rete virtuale.
Le chiamate client per risolvere il nome di rete virtuale nel sistema DNS restituiscono tutto l'indirizzo
IP registrato in una sequenza round robin variabile.
Istanze del cluster di failover AlwaysOn
Obiettivo principale di un'istanza del cluster di failover di SQL Server AlwaysOn è migliorare la
disponibilità di un'istanza di SQL Server ospitata nell'hardware del server e di archiviazione locale
all'interno di un singolo data center.
Un'istanza del cluster di failover è una singola istanza logica di SQL Server installata nei nodi di un cluster
WSFC (Windows Server Failover Clustering), ma attiva solo su un nodo per volta. Le applicazioni client si
connettono a un nome di rete virtuale e a un indirizzo IP virtuale di proprietà del nodo del cluster attivo.
Ogni nodo installato ha una configurazione e un set di file binari di SQL Server identici. Il servizio cluster
WSFC replica inoltre le modifiche pertinenti dalle voci dell'istanza attiva nel Registro di sistema di Windows
a ogni nodo installato. Ogni nodo in cui è installata l'istanza del cluster di failover è definito come
possibile proprietario dell'istanza e delle relative risorse, all'interno di una sequenza di failover preferita.
I file di database vengono archiviati su volumi di archiviazione simmetrici condivisi, registrati come risorsa
con il cluster WSFC e definiti di proprietà del nodo che attualmente ospita l'istanza del cluster di failover.
Per ulteriori informazioni, vedere Istanze del cluster di failover AlwaysOn (SQL Server)
(http://msdn.microsoft.com/it-it/library/ms189134(SQL.110).aspx).
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
19
Procedura di failover dell'istanza del cluster di failover
Se si verifica un problema in una risorsa cluster dipendente, un'istanza del cluster di failover AlwaysOn
interagisce con il servizio cluster WSFC utilizzando la procedura di alto livello seguente per eseguire un
failover.
1) Viene indicato un riavvio. Un controllo periodico della configurazione dei criteri di failover di WSFC
o SQL Server indica uno stato con errori. Per impostazione predefinita, viene tentato un riavvio del
servizio prima di avviare un failover a un altro nodo. Un timeout durante il tentativo di riavvio indica
un errore della risorsa.
2) Viene indicato un failover. Un controllo dei criteri di failover indica la necessità del failover di
un nodo.
3) Il servizio SQL Server viene arrestato. Se è in esecuzione, viene tentato un normale arresto del
servizio SQL Server.
4) La risorsa cluster WSFC viene trasferita. La proprietà del gruppo di risorse del cluster di SQL Server
e le relative risorse di rete e di archiviazione condivisa dipendenti vengono trasferite al successivo
proprietario del nodo preferito dell'istanza del cluster di failover.
5) SQL Server viene avviato sul nuovo nodo. L'istanza di SQL Server segue le normali procedure di
avvio. Se non ritorna online entro un periodo di timeout in sospeso, il servizio cluster inserisce la
risorsa su questo nuovo nodo indicandone uno stato con errori.
6) I database utente vengono ripristinati sul nuovo nodo. Ogni database utente viene posto in
modalità di ripristino mentre vengono effettuate le operazioni di rollforward dei log delle
transazioni e di rollback delle transazioni di cui non è stato eseguito il commit.
Miglioramenti apportati all'istanza del cluster del failover
Nelle versioni precedenti di SQL Server era disponibile un'opzione di installazione dell'istanza del cluster
di failover. L'affidabilità e la facilità d'uso della funzionalità sono ora maggiori grazie ad alcuni
miglioramenti introdotti in SQL Server 2012:
ο·
Clustering su più subnet. In SQL Server 2012 vengono supportati nodi del cluster WSFC che si
trovano in più di una subnet. Una data istanza di SQL Server che si trova in un nodo del cluster WSFC
può essere avviata se è disponibile un'interfaccia di rete qualsiasi. Questa caratteristica è nota come
dipendenza della risorsa cluster “OR”.
Nelle versioni precedenti di SQL Server era necessario che tutte le interfacce di rete fossero
funzionanti per consentire l'avvio o il failover del servizio SQL Server e che fossero tutte presenti
sulla stessa subnet o VLAN.
Nota: la replica a livello di archiviazione tra nodi del cluster non è abilitata in modo implicito con il
clustering su più subnet. Una soluzione basata sull'istanza del cluster di failover su più subnet dovrà
a sua volta fare uso di una soluzione basata su SAN di terze parti per replicare i dati e coordinare il
failover delle risorse di archiviazione tra i nodi del cluster.
Per ulteriori informazioni, vedere SQL Server 2012 AlwaysOn: Istanza del cluster di failover multisito
(http://sqlcat.com/sqlcat/b/whitepapers/archive/2011/12/22/sql-server-2012-alwayson_3a00_multisite-failover-cluster-instance.aspx).
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
20
ο·
Affidabile rilevamento degli errori. Il servizio cluster WSFC mantiene una connessione amministrativa
dedicata a ogni istanza del cluster di failover di SQL Server 2012 presente sul nodo. Su questa
connessione, una chiamata periodica a una speciale stored procedure di sistema, sp_server_diagnostics,
restituisce una matrice dettagliata di informazioni diagnostiche sull'integrità del sistema.
Prima di SQL Server 2012, il principale meccanismo di rilevamento dell'integrità di un'istanza del
cluster di failover veniva implementato come semplice processo di polling unidirezionale. In questo
processo, il servizio cluster WSFC creava periodicamente una nuova connessione client SQL all'istanza,
eseguiva una query del nome del server ed effettuava la disconnessione. Un errore di connessione
o un timeout della query, dovuti a un motivo qualsiasi, attivavano un failover con una quantità
estremamente ridotta di informazioni diagnostiche disponibili.
Per ulteriori informazioni, vedere sql_server_diagnostics (http://msdn.microsoft.com/it-it/
library/ff878233(SQL.110).aspx).
È ora disponibile un più ampio supporto per gli scenari di archiviazione delle istanze del cluster di
failover:
ο·
Migliore supporto del punto di montaggio. Nell'installazione di SQL Server vengono ora
riconosciute le impostazioni del punto di montaggio dei dischi del cluster. I dischi del cluster
specificati e tutti i dischi montati nel cluster vengono aggiunti automaticamente alla dipendenza
delle risorse di SQL Server durante l'installazione.
ο·
Database tempdb su risorse di archiviazione locali. Nelle istanze del cluster di failover è ora
supportata l'aggiunta di tempdb in risorse di archiviazione locali non condivise, come un'unità SSD,
che permette di scaricare potenzialmente una notevole quantità di operazioni di I/O da una rete
SAN condivisa.
Prima di SQL Server 2012, per le istanze del cluster di failover tempdb doveva trovarsi in un volume
di archiviazione condiviso simmetrico con failover con altri database di sistema.
Nota: il percorso di tempdb viene archiviato nel database master, che si sposta tra nodi durante il
failover. Deve essere un percorso di file simmetrico valido (unità, cartelle e autorizzazioni) su tutti
i potenziali proprietari dei nodi, altrimenti il servizio SQL Server non verrà avviato su alcuni nodi.
Disponibilità dei database
Le funzionalità di disponibilità elevata offerte dall'infrastruttura e dai componenti a livello di istanza di
SQL Server operano in combinazione per proteggere in modo implicito i database ospitati. Una soluzione
AlwaysOn offre un set aggiuntivo di opzioni per la protezione esplicita dei dati di database e delle
applicazioni livello dati.
Gruppi di disponibilità AlwaysOn
Un gruppo di disponibilità è un set di database utente di cui viene effettuato il failover simultaneo da
un'istanza di SQL Server a un'altra all'interno dello stesso cluster WSFC. Le applicazioni client possono
connettersi ai database del gruppo di disponibilità tramite un nome di rete virtuale del cluster WSFC,
noto come listener del gruppo di disponibilità, che separa le istanze di SQL Server sottostanti.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
21
I gruppi di disponibilità AlwaysOn si basano su Windows Server Failover Clustering per il monitoraggio
dell'integrità, il coordinamento del failover e la connettività del server. È necessario abilitare il supporto
AlwaysOn su un'istanza di SQL Server che si trova su un nodo del cluster WSFC, ma tale istanza non deve
essere un'istanza del cluster di failover, né utilizzare risorse di archiviazione condivise simmetriche.
Per ulteriori informazioni, vedere Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
(http://msdn.microsoft.com/it-it/library/ff877884(SQL.110).aspx).
Repliche di disponibilità e ruoli
Ogni istanza di SQL Server nel gruppo di disponibilità ospita una replica di disponibilità che contiene una
copia dei database utente nel gruppo di disponibilità. Un'istanza di SQL Server può ospitare solo una
replica di disponibilità di un dato gruppo di disponibilità, ma nella stessa istanza possono risiedere più
gruppi di disponibilità. L'istanza di SQL Server deve possedere volumi di archiviazione dedicati (non condivisi).
Una delle repliche di disponibilità svolge il ruolo di replica primaria. Questa replica è designata come
copia master dei database del gruppo di disponibilità e abilitata per le operazioni di lettura/scrittura.
Un gruppo di disponibilità può contenere da una a quattro repliche di disponibilità di sola lettura
aggiuntive, ciascuna delle quali svolge separatamente il ruolo di replica secondaria.
Sincronizzazione delle repliche di disponibilità
Il contenuto di ogni database in un gruppo di disponibilità è sincronizzato dalla replica primaria a ognuna
delle repliche secondarie tramite un meccanismo di spostamento di dati basato su log di SQL Server. Per
questo motivo, è necessario impostare tutti i database nel gruppo di disponibilità sul modello di
recupero con registrazione completa.
Le repliche secondarie vengono inizializzate con un backup e un ripristino completi dei database e dei
log delle transazioni della replica primaria. Man mano che viene eseguito il commit di nuove transazioni
nella replica primaria, la parte corrispondente del log delle transazioni viene memorizzata nella cache,
accodata e quindi inviata in rete a un endpoint del mirroring del database su ognuno dei nodi delle
repliche secondarie.
In questo modo, le nuove voci nel log delle transazioni della replica primaria vengono accodate
a ognuno dei log delle transazioni delle repliche secondarie. Ogni replica secondaria comunica
periodicamente un numero di sequenza del file di log (LSN) alla replica primaria per indicare la quantità
del proprio log delle transazioni finalizzata e scaricata sul disco remoto.
Nota: ogni replica di disponibilità possiede un proprio set di thread di rollforward dei log delle
transazioni indipendenti che non fanno parte del processo di sincronizzazione delle repliche di
disponibilità. Si potrebbero riscontrare ritardi sotto forma di latenza dei dati nel processo di rollforward
dei log sulle repliche secondarie.
Oltre a svolgere un ruolo primario o secondario, ogni replica di disponibilità è associata a una modalità
di disponibilità, che determina il coordinamento della finalizzazione dei log delle transazioni durante
un'istruzione COMMIT TRAN, come descritto di seguito.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
22
ο·
Modalità di commit sincrono. Nella replica primaria viene eseguito il commit di una transazione
specificata solo dopo che tutte le repliche secondarie con commit sincrono confermano di avere
completato la finalizzazione dei rispettivi log delle transazioni oltre il numero LSN di tale
transazione. Un gruppo di disponibilità può avere fino a due repliche secondarie con commit
sincrono.
La modalità di commit sincrono causa la latenza delle transazioni sui database della replica primaria,
ma assicura che non vi sia perdita di dati nelle repliche secondarie per le transazioni di cui è stato
eseguito il commit.
ο·
Modalità di commit asincrono. Nella replica primaria viene eseguito il commit delle transazioni
dopo la finalizzazione del log delle transazioni locali senza attendere che una replica secondaria con
commit asincrono confermi la finalizzazione del proprio log delle transazioni. Un gruppo di
disponibilità può avere fino a quattro repliche secondarie con commit asincrono, ma non più di
quattro repliche secondarie totali di qualsiasi tipo.
La modalità di commit asincrono riduce al minimo la latenza delle transazioni nei database della
replica primaria, ma permette un certo ritardo dei log delle transazioni delle repliche secondarie,
favorendo la perdita di dati.
Per ulteriori informazioni, vedere Modalità di disponibilità (gruppi di disponibilità AlwaysOn)
(http://msdn.microsoft.com/it-it/library/ff877931(SQL.110).aspx).
L'integrità complessiva del flusso di dati tra le repliche di disponibilità viene indicata dallo stato di
sincronizzazione di ogni replica. Sarà più probabile riscontrare una perdita di dati se il failover viene
eseguito su una replica secondaria associata uno stato di sincronizzazione diverso da “Sincronizzato”
o ”Sincronizzazione in corso”.
Il flusso di sincronizzazione di ogni replica secondaria dispone di una proprietà di timeout di sessione.
Quando in una replica secondaria configurata per una modalità di disponibilità con commit sincrono si
verifica un problema ed è impostato un timeout di sessione, la replica viene temporaneamente
contrassegnata come asincrona a livello interno. Questo avviene per evitare che l'errore della replica
secondaria abbia impatto sulla finalizzazione del log delle transazioni nella replica primaria. Quando la
replica secondaria torna integra e sincronizzata con la replica primaria, viene automaticamente
ripristinato il normale funzionamento in modalità di commit sincrono.
Failover del gruppo di disponibilità
Il gruppo di disponibilità e un nome di rete virtuale corrispondente sono registrati come risorse nel
cluster WSFC. Un gruppo di disponibilità viene sottoposto a failover a livello di una replica di
disponibilità, in base all'integrità e ai criteri di failover della replica primaria.
Nei criteri di failover di un gruppo di disponibilità viene utilizzata la proprietà FailureConditionLevel per
indicare il livello di tolleranza di gravità per un errore che interessa il gruppo di disponibilità, insieme alla
stored procedure di sistema sp_server_diagnostics. Questo stesso meccanismo viene utilizzato per
i criteri di failover delle istanze del cluster di failover.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
23
In caso di failover, anziché trasferire la proprietà delle risorse fisiche condivise a un altro nodo, si utilizza
WSFC per riconfigurare una replica secondaria su un'altra istanza di SQL Server in modo che assuma il
ruolo di replica primaria. La risorsa nome di rete virtuale del gruppo di disponibilità viene quindi trasferita
a tale istanza. Tutte le connessioni client alle repliche di disponibilità interessate vengono reimpostate.
In base all'attuale integrità, allo stato di sincronizzazione e alla modalità di disponibilità delle repliche,
a ogni replica è associato uno stato di conformità failover composto che indica il possibile rischio di
perdita di dati. Queste informazioni sull'integrità delle repliche sono visualizzabili nel dashboard
AlwaysOn o nella vista di sistema sys.dm_hadr_availability_replica_states.
Per ogni replica di disponibilità è inoltre configurata una modalità di failover che ne determina il
comportamento quando viene indicato il failover.
ο·
Failover automatico (senza perdita di dati). Questo tipo di failover è il più rapido per qualsiasi
configurazione AlwaysOn perché il log delle transazioni delle repliche secondarie è già finalizzato
e sincronizzato. Viene eseguito il rollback delle transazioni aperte nella replica primaria e il ruolo
della replica primaria viene trasferito a una replica secondaria senza alcun intervento dell'utente.
È necessario impostare la replica primaria e la replica secondaria sulla modalità di failover
automatico e sulla modalità di disponibilità con commit sincrono. Lo stato di sincronizzazione tra le
repliche deve essere “Sincronizzato”. Inoltre, il cluster WSFC deve possedere un quorum integro.
Il failover automatico non è supportato se la replica primaria o secondaria si trova in un'istanza del
cluster di failover, per evitare una situazione di race condition potenziale tra failover del gruppo di
disponibilità e dell'istanza del cluster di failover.
ο·
Failover manuale. Questo tipo di failover consente all'amministratore di valutare lo stato della
replica primaria e stabilire se effettuare deliberatamente il failover su una replica secondaria
o meno.
A seconda della modalità di disponibilità e dello stato di sincronizzazione, è possibile scegliere tra le
opzioni seguenti:
o
Failover manuale pianificato (senza perdita di dati). È possibile eseguire questo tipo di failover
solo se le repliche primaria e secondaria sono entrambe integre e con stato “Sincronizzato”.
Questo caso è funzionalmente equivalente a un failover automatico.
o
Failover manuale forzato (con potenziale perdita di dati). Si tratta dell'unica forma di failover
possibile se la replica secondaria di destinazione si trova in modalità di disponibilità con commit
asincrono o se non è sincronizzata con la replica primaria.
Avviso: questa opzione di failover deve essere utilizzata solo in una situazione di ripristino di
emergenza. Se la replica primaria è integra e disponibile, è necessario modificare la modalità di
disponibilità delle repliche interessate in commit sincrono ed eseguire quindi un failover
manuale pianificato.
Per ulteriori informazioni, vedere Eseguire un failover manuale forzato di un gruppo di
disponibilità (SQL Server) (http://msdn.microsoft.com/it-it/library/ff877957(SQL.110).aspx).
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
24
È necessario eseguire un failover manuale se sussiste una qualsiasi delle condizioni seguenti nella replica
primaria o nella replica secondaria su cui effettuare il failover.
ο·
ο·
ο·
La modalità di failover è impostata su manuale.
La modalità di disponibilità è impostata sul commit asincrono.
La replica si trova in un'istanza del cluster di failover.
Per ulteriori informazioni, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn)
(http://msdn.microsoft.com/it-it/library/hh213151(SQL.110).aspx).
Nota: dopo un failover, se la nuova replica primaria non è impostata sulla modalità con commit
sincrono, le repliche secondarie indicheranno uno stato di sincronizzazione “Sospeso”. Nessun dato
verrà propagato alle repliche secondarie se la replica primaria non viene prima impostata sulla modalità
con commit sincrono.
Listener del gruppo di disponibilità
Un listener del gruppo di disponibilità è un nome di rete virtuale (VNN) di WSFC che i client possono
utilizzare per accedere a un database nel gruppo di disponibilità. La risorsa cluster VNN è di proprietà
dell'istanza di SQL Server in cui si trova la replica primaria.
Il nome di rete virtuale viene registrato con il sistema DNS solo durante la creazione del listener del
gruppo di disponibilità o durante le modifiche alla configurazione. Tutti gli indirizzi IP virtuali definiti nel
listener del gruppo di disponibilità vengono registrati con il sistema DNS sotto lo stesso nome di rete
virtuale.
Per utilizzare il listener del gruppo di disponibilità, una richiesta di connessione client deve specificare
il nome di rete virtuale come server e il nome di un database presente nel gruppo di disponibilità.
Per impostazione predefinita, questo comportamento deve produrre una connessione all'istanza di
SQL Server che ospita la replica primaria.
In fase di esecuzione, il client utilizza il risolutore DNS locale per ottenere un elenco di indirizzi IP e porte
TCP mappate al nome di rete virtuale. Il client tenta quindi di connettersi a ognuno degli indirizzi IP, fino
a stabilire la connessione o a raggiungere il timeout. Il client tenterà di stabilire queste connessioni in
parallelo se il parametro MultiSubnetFailover è impostato su true, consentendo failover del client molto
più rapidi.
In caso di failover, le connessioni client vengono reimpostate sul server, la proprietà del listener del
gruppo di disponibilità viene trasferita insieme al ruolo di replica primaria alla nuova istanza di SQL
Server e l'endpoint del VNN viene associato agli indirizzi IP virtuali e alle porte TCP della nuova istanza.
Per ulteriori informazioni, vedere Listener del gruppo di disponibilità, connettività client e failover
dell'applicazione (SQL Server) (http://msdn.microsoft.com/it-it/library/hh213417(SQL.110).aspx).
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
25
Filtro della finalità dell'applicazione
Durante la connessione tramite il listener del gruppo di disponibilità, è possibile specificare se la finalità
dell'applicazione corrisponde alla lettura e alla scrittura di dati o all'esclusiva esecuzione di operazioni di
sola lettura. Se non è specificata, la finalità predefinita dell'applicazione per il client corrisponde
a lettura e scrittura.
Per il ruolo primario e il ruolo secondario di ogni replica di disponibilità, è possibile specificare anche una
proprietà di accesso alla connessione che sarà utilizzata come filtro a livello di connessione sulla finalità
dell'applicazione del client. Per impostazione predefinita, le combinazioni non valide di finalità
dell'applicazione e accesso alla connessione hanno come risultato una connessione rifiutata. Le richieste
di connessione client devono essere escluse da SQL Server utilizzando le regole seguenti.
Mentre la replica di disponibilità riguarda il ruolo primario e l'accesso alla connessione corrisponde alle
impostazioni seguenti, vengono effettuate le azioni indicate di seguito.
ο·
ο·
Consenti qualsiasi finalità dell'applicazione. Le connessioni client non vengono filtrate in base
alla finalità dell'applicazione.
Consenti solo finalità di lettura/scrittura esplicita. Se il client specifica la sola lettura, la
connessione viene rifiutata.
Mentre la replica di disponibilità riguarda il ruolo secondario e l'accesso alla connessione corrisponde
alle impostazioni seguenti, vengono effettuate le azioni indicate di seguito.
ο·
ο·
ο·
Nessuna connessione consentita. Tutte le connessioni vengono rifiutate e la replica viene
utilizzata solo per il ripristino di emergenza.
Consenti qualsiasi finalità dell'applicazione. Le connessioni client non vengono filtrate in base
alla finalità dell'applicazione.
Finalità di sola lettura dell'applicazione. Se il client non specifica la sola lettura, la connessione
viene rifiutata.
Per ulteriori informazioni, vedere Configurare l'accesso in sola lettura in una replica di disponibilità (SQL
Server) (http://msdn.microsoft.com/it-it/library/hh213002(SQL.110).aspx).
Routing di sola lettura della finalità dell'applicazione
Una caratteristica estremamente valida di Gruppi di disponibilità AlwaysOn è la possibilità di sfruttare
l'infrastruttura hardware di standby per scopi diversi dal ripristino di emergenza. Configurando una o più
repliche secondarie per l'accesso in sola lettura, è possibile scaricare carichi di lavoro significativi dalle
repliche primarie.
I carichi di lavoro che possono essere facilmente adattati all'elaborazione su una replica secondaria di
sola lettura includono la creazione di report, i backup dei database, le verifiche di coerenza dei database,
l'analisi della frammentazione dell'indice, l'estrazione della pipeline di dati, il supporto operativo e le
query ad hoc.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
26
Per ogni replica di disponibilità, è possibile configurare facoltativamente un elenco di routing di sola
lettura sequenziale di endpoint dell'istanza di SQL Server da applicare mentre la replica è nel ruolo
primario. Se presente, questo elenco viene utilizzato per reindirizzare le richieste di connessione client
in cui è specificata la finalità di sola lettura dell'applicazione alla prima replica secondaria disponibile
nell'elenco che soddisfa i filtri della finalità dell'applicazione indicati in precedenza.
Nota: il reindirizzamento del routing di sola lettura viene eseguito dal listener del gruppo di disponibilità,
associato alla replica primaria. Se la replica primaria è offline, il reindirizzamento del client non funzionerà.
Per ulteriori informazioni, vedere Configurare il routing di sola lettura in un gruppo di disponibilità (SQL
Server) (http://msdn.microsoft.com/it-it/library/hh653924(SQL.110).aspx).
Miglioramenti alla disponibilità - Database
SQL Server 2012 include una serie di miglioramenti specifici della configurazione e delle funzionalità dei
database.
Il miglioramento indicato di seguito consente di ridurre il tempo di recupero:
ο·
Tempo di recupero prevedibile. È possibile impostare un intervallo di tempo di recupero di
destinazione per ogni database, da utilizzare per controllare la pianificazione di un comando
CHECKPOINT in background. Questo checkpoint indiretto si verifica periodicamente, in base alla
stima del tempo necessario per recuperare il log delle transazioni in caso di riavvio o di failover.
Questa funzionalità ha come effetto di uniformare le operazioni di I/O in proporzioni più o meno
uguali per ogni checkpoint e aumentare la prevedibilità del tempo di recupero (RTO).
Prima di SQL Server 2012, i comandi CHECKPOINT in background venivano emessi in base a un
intervallo fisso, indipendentemente dal volume o dal carico delle transazioni, il che poteva
provocare tempi di recupero imprevedibili.
Per ulteriori informazioni, vedere Checkpoint di database (SQL Server)
(http://msdn.microsoft.com/it-it/library/ms189573(SQL.110).aspx).
I miglioramenti indicati di seguito consentono di intervenire su scenari comuni che possono condurre
a tempo di inattività pianificato.
ο·
Operazioni sugli indici online per le colonne LOB. Gli indici che contengono colonne con tipi di dati
varbinary(max), varchar(max), nvarchar(max) o XML possono ora essere ricompilati o riorganizzati
online.
ο·
Modifica dello schema online per le nuove colonne NOT NULL. Se una nuova colonna NOT NULL
viene aggiunta con un valore predefinito a una tabella di database di SQL Server 2012, è necessario
solo un blocco dello schema per aggiornare i metadati del sistema, anziché dover popolare tutte le
righe durante l'istruzione ALTER TABLE.
SQL Server renderà fisicamente persistente il valore di colonna predefinito solo se viene
effettivamente modificata o reindicizzata una riga. Le query restituiscono il valore predefinito dai
metadati, a meno che non esista un valore di colonna effettivo.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
27
Di seguito viene descritto un esempio di più ampio supporto per gli scenari di archiviazione.
ο·
Correzione automatica della pagina. Determinati tipi di errori del sottosistema di archiviazione
possono danneggiare una pagina di dati, rendendola illeggibile. I gruppi di disponibilità AlwaysOn
possono rilevare questi tipi di errori e ripristinare la situazione precedente richiedendo in modo
asincrono una copia aggiornata delle pagine di dati interessate a una replica di disponibilità diversa
e quindi applicando la copia.
Una funzionalità simile esisteva prima di SQL Server 2012 per il mirroring del database, ma è stata
migliorata e supporta più repliche.
Per ulteriori informazioni, vedere Correzione automatica della pagina (Gruppi di disponibilità/Mirroring
del database) (http://msdn.microsoft.com/it-it/library/bb677167(SQL.110).aspx).
Consigli sulla connettività client
Le linee guida seguenti consentono di sfruttare al meglio le tecnologie Microsoft SQL Server 2012
AlwaysOn per le applicazioni client.
ο·
Libreria client compatibile con AlwaysOn. Utilizzare una libreria client che supporta il protocollo
TDS versione 7.4 o successiva. In questo modo dovrebbe essere assicurata la funzionalità lato client
desiderata per l'utilizzo di AlwaysOn. Librerie client di esempio includono il Provider di dati per SQL
Server in .NET Framework 4.02 e SQL Native Client 11.0.
ο·
Proprietà del provider di connessione: MultiSubnetFailover = True. Utilizzare questa parola chiave
nelle stringhe di connessione per consentire alle librerie client di tentare connessioni in parallelo
a tutti gli indirizzi IP registrati per il listener del gruppo di disponibilità o all'istanza del cluster di
failover associata a un indirizzo IP in più subnet.
ο·
Proprietà del provider di connessione: ApplicationIntent = ReadOnly. Se fattibile, scaricare i carichi
di lavoro di sola lettura dalla replica primaria sulle repliche secondarie.
ο·
Timeout delle connessione client legacy. Poiché le librerie di database client legacy non
implementano tentativi di connessione paralleli, in presenza di più indirizzi IP tentano di connettersi
in sequenza a ognuno di essi, fino a un timeout TCP o a stabilire una connessione.
È necessario modificare il timeout della connessione sui client legacy in modo da tenere in
considerazione i possibili timeout e tentativi sequenziali in presenza di più indirizzi IP, impostandolo
su un valore di almeno 15 secondi + 21 secondi per ogni replica secondaria.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
28
Conclusione
In questo white paper è stato delineato il contesto di base per ridurre il tempo di inattività pianificato
e non pianificato, ottimizzare la disponibilità delle applicazioni e fornire protezione dati utilizzando le
soluzioni per la disponibilità elevata e il ripristino di emergenza di SQL Server 2012 AlwaysOn.
Molti dei principi guida aziendali e delle problematiche in materia di pianificazione, gestione
e misurazione di un ambiente di database a disponibilità elevata possono essere quantificati ed espressi
in termini di obiettivi del punto di recupero (RPO) e obiettivi del tempo di recupero (RTO).
SQL Server 2012 AlwaysOn fornisce funzionalità a livello di infrastruttura, piattaforma di dati e database
in grado di supportare i comuni scenari di disponibilità elevata e ripristino di emergenza in modo
pienamente giustificabile utilizzando gli obiettivi RPO e RTO.
Per ulteriori informazioni
http://www.microsoft.com/italy/server/sql/: sito Web SQL Server
http://technet.microsoft.com/it-it/sqlserver/: TechCenter di SQL Server
http://msdn.microsoft.com/it-it/sqlserver/: Risorse online per gli sviluppatori di SQL Server
Il documento è risultato utile? Esprimere una valutazione utilizzando una scala compresa tra
1 (scarso) e 5 (eccellente), indicandone i motivi. Ad esempio:
ο·
ο·
La valutazione è alta perché il documento contiene esempi validi, catture di schermate
nitide, spiegazioni chiare o altri motivi?
La valutazione è bassa perché il documento contiene esempi confusi, catture di
schermate sfocate, spiegazioni poco chiare?
I commenti aiuteranno Microsoft a migliorare la qualità dei white paper pubblicati.
Commenti e suggerimenti.
◊ Versione 1.1, 21 febbraio 2012.
Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza
29
