SQL Server 2012 AlwaysOn: Availability Group, Installazione – Parte 1

Article
04/17/2013

Buongiorno a tutti!

Per l’articolo di oggi ringraziamo Ruggiero Lauria. Ecco una sua breve descrizione:

“Mi sono laureato in Economia, ma la passione tecnica ha prevalso portandomi a specializzarmi nell’ambito sistemistico Microsoft. Da lì ho continuato a coltivare la doppia anima di System e Database Administrator. Dal 2004 sono MCSE e con l’avvento delle versioni Windows e SQL Server 2008 ho aggiornato le mie competenze alle ultime certificazioni, cosa che mi ha portato a diventare anche MCT e collaborare con vari CPLS.Attualmente lavoro come freeland nel settore della formazione tecnica e della consulenza specialistica su reti Microsoft e Database SQL server.”

L’articolo è stato diviso in due parti, di seguito la prima parte. Nella seconda parte verrà trattata la configurazione e il Read-Only Routing.

Introduzione

Una delle più grandi novità introdotte da SQL Server 2012 sotto il profilo dell' alta disponibilità è la tecnologia AlwaysOn.
Questa si suddivide in due tipologie:

1. AlwaysOn Failover Cluster Instance: Protezione a livello di singola istanza, miglioramento della tradizionale installazione in Cluster di SQL Server nel monitoraggio dello stato di salute e nelle implementazioni Multi-Subnet

2.AlwaysOn Availability Group: Protezione a livello di Database, evoluzione del DB mirroring delle versioni precedenti di SQL Server

La prima soluzione in termini architetturali poco aggiunge alle precedenti versioni se non l'eliminazione della necessità di creazione di una VLAN per i nodi del cluster; invece i gruppi di diponibilità sono una vera novità, forse uno di quei particolari per cui varrebbe la pena di migrare a SQL 2012.

AlwaysOn Availability Group

Generale
Questa tecnologia sfrutta i vantaggi offerti dal Windows Server Failover Cluster (WSFC) per fornire una soluzione di alta disponibilità per i Database SQL Server. E' una evoluzione della tecnologia di DB mirroring, introdotta con la versione SQL Server 2005, ma offre questi fondamentali vantaggi aggiuntivi:

1. Il numero dei nodi non è più limitato a 2

2. Il failover non è più fatto dal client, ma avviene lato server in maniera trasparente per i client

3. E' possibile accedere in sola lettura ad un nodo passivo del gruppo di disponibilità

4. E' possibile eseguire le operazioni di backup su un nodo passivo del gruppo di disponibilità

Nonostante questa tecnologia si basi sul Failover Cluster non è necessario:

1. Avere uno storage condiviso fra i nodi del cluster

2. Fare un installazione in Cluster di SQL Server

Quindi ogni nodo avrà un'installazione autonoma di SQL Server con i dati su uno storage locale del nodo.
Note:

· In Windows Server 2012 la funzionalità di Failover Cluster è disponibile anche sulla versione Standard

· Non esiste nessun problema nel creare nodi virtualizzati, se non le solite raccomandazioni relative al fare girare SQL Server su una macchina virtuale

Terminologia

AlwaysOn Availability Group : gruppo diserver (in cluster) che mette in alta disponibilità uno o più Database
Primary Replica: istanza che ospita la copia in lettura e scrittura del Database
Secondary Replica: host che ospita una copia del database su cui è possibile abilitare accessi in sola lettura
Listener: consiste di un nome DNS, una porta TCP ed uno o più indirizzi IP attraverso cui i client si connettono al gruppo di disponibilità
Availability Modes: modalità di replica dei dati fra il membro primario ed i secondari, può essere:

1. Commit-Synchronous: la replica primaria attende conferma che le modifiche siano state apportate sul membro secondario prima di chiudere la transazione . Affidabile ma pericoloso per le performances

2. Commit-Asynchronous: il membro primario invia le modifiche al secondario e chiude la transazione senza aspettare conferma sull'esito.Non affidabile ma performante.

Failover: processo attraverso il quale il ruolo di replica primaria viene passato ad una replica secondaria, chiamata failover target. Sono disponibili 3 tipi di failover:

1. Failover automatico (senza perdita di dati): disponibile quando sia la replica primaria che la secondaria operano in modalità sincrona ( Commit-Synchronous). In questo caso la modalità di failover nel gruppo è impostata su automatica ed il passaggio di ruoli avviene senza alcun intervento amministrativo.

2. Failover manuale pianificato (senza perdita di dati): come nel caso precedente i due membri operano in modalità sincrona, ma non essendo stato impostato il failover automatico è necessario l'intervento amministrativo per inviare il comando di failover.

3. Failover manuale forzato (con possibile perdita di dati): i due membri di replica operano in modalità asincrona e quindi l'amministratore può forzare il failover sapendo che eventuali transazioni del membro primario non ancora sincronizzate andranno perse.

Active Secondary Replicas: per migliorare le performance e gestire in maniera più efficiente le risorse del gruppo di disponibilità è possibile indirizzare le richieste di sola lettura e backup verso repliche secondarie

Installazione
L'obiettivo di questo articolo è centrato sugli Availability Group e non sulla configurazione del Cluster di Failover, quindi non entrerò nei dettagli su questa parte.
1) Installare la funzionalità di Failover Cluster sui Server

2) Creare un Cluster di Failover che comprenda tutti i Server

Nel nostro esempio abbiamo creato un cluster MIA-CLUSTER a cui partecipano i server:
MIA-CLUST1
MIA-CLUST2
MIA-CLUST3
Notare che nel Cluster non c'è Storage condiviso.

3) Installare un'istanza Standalone di SQL Server 2012 su ogni Server

Note:

· Usate un account di dominio per il Servizio SQL

· Potete installare solo il Motore di Database, opzionalmente anche gli strumenti di gestione

4) Attaverso il Configuration Manager abilitate AlwaysOn Availability Group su ogni Server

Riavviate i servizi di SQL Server
5) Create una condivisione di rete per i file di Backup utilizzati per sincronizzare le repliche

6) Creiamo i DataBase che vogliamo proteggere sul Server che diventerà la Replica Primaria

Nel nostro caso il Server che svolgerà il ruolo di Replica Primaria è MIA-CLUST1 e mettiamo in alta disponibilità il Database Sales.
Controllate che il Recovery Model sia Full