Il Database Mirroring, o cluster dei poveri ;-) , consente di "replicare" le transazioni dal database Principal al database Mirror.
In pratica le applicazioni si connettono al database Principal e tutti i comandi che comportano la modifica ai dati o alla struttura
vengono replicati esattamente sul Mirror.
In Sql Server 2012 il Database Mirroring è considerato deprecated ma il suo erede, l' Always On Availability Group, è il sostituto ideale perchè consente di superare i numerosi limiti di funzionamento della vecchia tecnologia.
Always on, per esempio, consente di avere fino a 4 nodi di replica sia sincrona che asincrona, di cui 2 in modalità Automatic Failover, cosa che il mirroring si sognava.
Inoltre non è necessario avere un server di witness per implementare un failover automatico, la modalità di funzionamento dell'Always On non lo richiede.
Ma come fa ad eseguire il failover automatico senza un witness ? Semplicemente appoggiandosi al failover cluster del sistema operativo;
per poter utilizzare l'always on è quindi indispensabile configurare il SO.
Vediamo come crearlo .
Dobbiamo connetterci utilizzando uno user con diritti amministrativi su tutti i nodi che vogliamo aggiungere....
Passo 1: Configurare il SO
Aggiungiamo le Features .Net Framework 4.5 e Failover Clustering.
Una volta fatto ciò, con il tool Failover Cluster Manager creiamo un nuovo Cluster...
Niente paura, è molto più semplice di quanto si possa immaginare :-)
La prima cosa che ci chiede è il nome dei server che faranno parte del cluster.
Scegliamo poi il nome del nostro cluster, nel mio caso ho scelto MyPoorCluster e assegnamogli un ip libero
A questo punto parte l'attività di creazione del cluster
Ed eccolo qui già funzionante... Semplice no ?
Se il log finale vi da dei warning non preoccupatevi, tenete presente che non abbiamo configurato il Quorum del cluster, in questo caso a noi non serve.
Passo 2: Configurare SQL Server 2012
Entriamo nel SQL Server Configuration Manager di ogni nodo inserito nel cluster, selezioniamo l'istanza e abilitiamo l'Always On.
ATTENZIONE : QUESTA OPERAZIONE RICHIEDE IL RESTART DELL'ISTANZA STESSA!!
Ora effettuiamo il full backup del/dei database che vogliamo ridondare. Dal SQL Server Management Studio, aperto sull'istanza che sarà la principale, espandiamo il nodo Always On e creiamo un nuovo Availability Group
Scegliamo il/i database che faranno parte del gruppo. Rispetto al Database Mirroring che doveva essere configurato per ogni database che si desiderava ridondare, l'Always On consente di gestire più database in un solo Availability Group. Posso includere solo Database con Recovery model FULL.
e configuriamo la modalita di failover, automatica o manuale e se il database secondario potrà essere acceduto in lettura dai client.
Questa è una cosa che con il Database Mirroring non era possibile implementare se non con il Database Snapshot, con tutti i problemi connessi relativi all'aggiornamento dello stesso...
La possibilità di leggere i DB secondari è un ulteriore vantaggio dell'Always On e consente di effettuare, per esempio, attività di reportistica che non impattano sulle performance del server principale.
Scegliamo ora un path accessibile a tutti i server di replica che conterrà il backup del DB
Click su next e parte la fase di validazione seguita dalla fase di creazione dell'Always On availability Group appena configurato.
D'ora in poi ogni transazione effettuata sul DB principal verrà "replicata" su TUTTI i nodi di replica selezionati precedentemente.
Tra il nodo Win8server e Win8Mirror inoltre il failover l'ho cofigurato in modalità automatica.
Se Win8Server non dovesse essere disponibile sarebbe possibile accedere in Lettura/Scrittura su Win8Mirror senza alcun intervento manuale.
Win8Mirror1 invece è in failover manuale cioè per attivare Win8mirror1 come server principale siamo costretti ad eseguire manualmente l'upgrade
del ruolo da secondario a principale. Questo perchè come già detto Always On supporta fino a 2 nodi in failover automatico.
Inoltre la modalità di replica l'ho configurata asincrona che praticamente equivale alla modalità High Performance del mirroring.
In pratica la transazione viene considerata conclusa dal client prima che sia stata replicata su Win8Mirror1 ma attenzione, potremmo subire
perdite di dati !!!! (In produzione ci penserei 4 volte prima di utilizzare la modalita Asincrona....)
Ecco come appare la dashboard dell'Availability Group nel caso in cui Win8server non dovesse essere disponibile.
Win8Mirror diviene il principal senza alcun intervento dell'amministratore.
Ciao
Luca
Nessun commento:
Posta un commento