SQL Server Mirroring e Clustering: una “convivenza” possibile

Mi è stato più volte chiesto se fosse supportata da Microsoft la combinazione di SQL Server Clustering e Database Mirroring.

Prima di tutto è utile fare un passo indietro, e chiedersi quali siano gli scenari in cui questo mix possa risultare utile.

SQL Server Clusterizzato lavora a livello di istanza, e forisce una soluzione di High Availability che permette al servizio di SQL Server (e a tutte le risorse da cui esso dipende) di realizzare un failover su un’altro sistema (fisico o virtuale) a fronte di un guasto Hardware o Software. La sola implementazione del Clustering non copre scenari di Disk Failure, o più in generale di perdita o corruzione di file di database (data o log), o di Disaster Recovery.

Se da un lato è possibile ricorrere a soluzioni di Data Replication fornite dai vendor SAN, a partire da SQL Server 2005 SP1 è possibile utilizzare il Database Mirroring per “replicare” i file di dei soli database utente su una seconda istanza presente sul notro sito di DR, rilasciando quindi la completa gestione dell’attività di “copia” a SQL Server. Implementando il failover automatico del database mirroring (modalità High Availability con Witness), è possibile fare in modo che, a fronte di un guasto sul sito principale, i nostri database si ritrovino in automatico pronti per l’uso sul sito di DR.

Tutto perfetto. A meno di errori architetturali e/o di configurazione. 

1) E’ sempre bene ricordare che il Database Mirroring lavora a livello di Database, e non di Istanza. Quindi:

• Se vogliamo gestire un sito di DR per tutta la nostra istanza, è bene implementare il mirroring di TUTTI i database contenuti nell’istanza (a parte i DB di sistema)
• Poichè il guasto sul sito principale potrebbe avvenire a livello di singolo DB, (invece che a livello di intera istanza), ricordiamoci che se abbiamo un applicativo che necessita di più DB sulla stessa istanza, dobbiamo ingegnarci e trovare modo di forzare il failover di tutti i DB legati all’applicativo a fronte del failover del DB su cui è stato innescato il failover.
• Il mirroring non ha un sistema di gestione delle dipendenze quindi in caso di applicazioni distribuite dove si ha la necessita di una sequenza di avvio dei database si deve gestire dall’applicazione
• Come detto in precedenza il mirroring non puo essere configurato per i database di sistema (Fare attenzione quindi se esiste la necessita’ di sincronizzare jobs, login, roles etc. Si deve implementare una soluzione custom a parte)
• Una volta eseguito il fail-over al sito di DR si deve gestire la redirezione delle conessioni(da tenere a mente che a differenza del cluster l’istaza SQL che agisce come mirror e’ un istanza con prorpio IP, nome macchina etc.)

2) Immaginiamoci il seguente scenario.

Cluster a due nodi con singola istanza SQL sul sito principale, Mirror in DR (clusterizzato o standalone, poco importa). Abbiamo un guasto hardware sul primo nodo, dove la nostra istanza SQL Server era attiva. Cosa vorremmo che accadesse? Sicuramente vorremmo mantenere il servizio attivo sul sito principale, e quindi vorremmo che in automatico venisse eseguito un failover dal primo al secondo nodo. Peccato che, se non interveniamo modificando il comportamento del mirroring, di default ci ritroveremmo operativi sul nodo DR. Questo perchè il failover del Mirroring è molto più veloce del Failover del Clustering.

Nel mirroring viene inviato un messaggio di “ping” ogni secondo, e in caso di mancata risposta viene eseguito il failover dopo 10 secondi. Nel caso del clustering, un failover impiega circa 60-90 secondi (più tempi vari di analysis,redo(rolll forward) e undo(roll back) con quest’ultima non incidente nei tempi di fail-over in caso di enterprise edition(Fast Recovery) e di inizializzazione dei file del temdb – a mano che non sia stato implementata l’instant file initialization valida solo per i file dati non per i log).  

A fronte di un semplice failover del cluster, quindi, il witness non vede i database “mirrorati” per 10 secondi, e di conseguenza scatena un failover su DR.

E’ bene quindi, nel caso di implementazione del Mirroring con Cluster, modificare questo tempo di failover di default, e aumentarlo, ad almeno 90 secondi:

ALTER

DATABASE nomedatabase SET PARTNER TIMEOUT 90;

GO

3) Immaginiamoci di avere un sito principale, diciamo a Segrate, che contiene il nostro Cluster e il nostro Witness. Un sito di DR a Roma.

Immaginiamoci che l’intero nostro sito principale non risulti più disponibile. Cosa vorremmo che accadesse? Probabilmente che tutti i nostri database effettuassero un failover sull’istanza di Roma. Cosa accadrebbe invece? Nulla. Nessun failover. Senza il witness (che, trovandosi nella sede pricipale, è fuori uso a sua volta), perdiamo la possibilità di failover automatico. E’ quindi bene “posizionare” il notro witness in un sito che sia strategico rispetto agli scenari che vorremmo poter gestire, e quindi anche rispetto alla perdita di un sito intero. La soluzione migliore sarebbe quella di avere un terzo sito.

Per ricapitolare.

Microsoft supporta la convivenza di SQL Server Mirroring e Clustering.

Nel progettarne l'architettura però, è sempre bene verificare che tutti i possibili scenari di failure siano stati rivisti e testati, e che le configurazioni siano state adattate per poter ottenere il comportamento desiderato.

- Beatrice Nicolini -