Esporta (0) Stampa
Espandi tutto

Alta disponibilità con SQL Server 2005

Di Andrea Benedetti - Microsoft MVP

In questa pagina

Introduzione Introduzione
Clustering di failover Clustering di failover
Mirroring del database Mirroring del database
Log shpping Log shpping
Replica Replica
La scelta di una soluzione appropriata La scelta di una soluzione appropriata

Introduzione

Nel mondo ideale un’applicazione database deve poter sempre essere attiva e utilizzabile (always ON), sempre disponibile 24 ore su 24, ovvero, in caso di malfunzionamento e/o indisponibilità dei dati, i dba devono essere in grado di ridurre al minimo il tempo di inattività delle applicazioni e di irraggiungibilità delle informazioni.

Questo significa, per i Database Administrator, poter disporre del più alto livello di disponibilità, sia di server che di database, sia in downtime pianificati (upgrade hardware, aggiornamenti di sistema operativo e/o di applicazioni, operazioni di manutenzione, …), che non pianificati (errori umani, crash di sistema, recovery di dati corrotti, disastri naturali, …).

SQL Server 2005 estende le funzionalità già presenti con la versione precedente fornendo una serie di strumenti per soluzioni di alta disponibilità dei dati da utilizzare per assicurare un servizio dei nostri database affidabile, sicuro e continuativo.

Le soluzioni offerte spaziano dalle possibilità di “online management” (manutenzione online degli indici, reorganize live, online restore, …), operazioni di fast recovery (in SQL Server 2000 il database diventa disponibile al completamente delle operazioni di undo, con SQL Server 2005 il database diventa disponibile all’inizio delle operazioni di undo), database mirroring (site protection), repliche (ridondanza dei dati), clustering (alta disponibilità di sistemi hardware).

La soluzione per eccellenza di alta disponibilità è sicuramente il clustering che, prescindendo da soluzioni di ridondanza dei dischi (RAID), non fornisce alcuna protezione su possibili danni allo storage.

Oltre a questo una soluzione basata sul cluser necessita, evidentemente, di hardware particolare e certificato e, chiaramente, ridondante.

Oltre a questa soluzione, se SQL Server 2000 offriva due validi strumenti come il log shipping e tre tipologie di replica, SQL Server 2005 offre tre nuove tipologie di replica (eterogenea per replicare dati da Oracle verso SQL Server, peer-to-peer, e over-http) e un nuovo e validissimo strumento: il database mirroring (disponibile per scenari sincroni e/o asincroni).

Nella griglia sottostante è possibile analizzare, per ogni tecnologia di alta disponibilità, le varie caratteristiche di ogni strumento.

SQL - Fig1

Salta subito all’occhio come il mirroring possa, in molti casi, essere uno strumento ideale: in modalità sincrona ci permette di non avere perdita di dati, ci consente di avere un failover automatico con un tempo bassissimo (il tempo più basso che si può ottenere con tutte le tecnologie a disposizione), può essere trasparente al client (posso inserire, nella connection string della mia applicazione, il partner di failover. In caso di failure sarà l’applicazione stessa a ridirigersi verso la macchina partner), ha una granularità di database (quindi non devo, se non mi serve, lavorare a livello di istanza), non necessita di hardware specifico o certificato ed ha una complessità di realizzazione molto bassa.

Certamente è vero che non esiste “lo” strumento ideale ma tanti strumenti che, a seconda delle necessità aziendali e comunque dello scenario applicativo, possono essere scelti per rispondere nel miglior modo possibile alle mie esigenze.

La scelta potrebbe dipendere, ad esempio, dalla necessità di non dover assolutamente perdere dei dati (e quindi mirroring o clustering), poter lavorare con una granularità di database (mirroring o log shipping), avere un tempo di failover più basso possibile (mirroring).

Per quanto riguarda invece le varie soluzioni di licensing di SQL Server dovremo, anche qui, scegliere la versione che consente di utilizzare le tecnologie di alta disponibilità che vogliamo implementare per i nostri database. Parlando di mirroring, ad esempio, la scelta di poter utilizzare con questa tecnologia con snapshot di database, ovvero “foto” in sola lettura dei nostri dati, può essere fatta solo con la versione Enterprise.

SQL - Fig 2

Vediamo allora di definire con una piccola panoramica gli strumenti a disposizione e quello che possono fornirci.

Clustering di failover

Costruito su Microsoft Clustering Services, è una combinazione di uno o più server (nodi del cluster) con due o più dischi condivisi. È la soluzione ottimale per mantenere i nostri database online in presenza di problemi hardware e downtime pianificati.

In caso di failure hardware il sistema sarà in grado, in maniera automatica, di continuare a lavorare spostando il carico sulla parte (nodo) attiva; in caso di manutenzione programmata, invece, abbiamo a disposizione dei comandi per configurare il “crash” di un nodo verso un altro così da assicurare agli utenti la continua disponibilità dell’applicazione.

Per utilizzare questo strumento SQL Server, inteso come applicazione, viene installato su un gruppo cluster a cui verrà associato un nome virtuale, indipendente dai nodi fisici.

Per questo motivo un’applicazione, collegandosi al nome virtuale, non ha alcuna necessità di sapere su quale nodo stia effettivamente lavorando e, allo stesso modo, viene visto sulla rete come un singolo computer.

È possibile configurare un’istanza su un nodo in modo che prenda il controllo nel caso in cui il nodo attivo subisca un errore hardware, di sistema operativo o di aggiornamenti pianificati.

È possibile utilizzare questa tecnologia anche con le versioni precedenti ma con la versione Enterprise di SQL Server 2005 possiamo estenderne le capacità fino a otto nodi (con Windows Server 2003 Datacenter Edition) e potendo utilizzare tutti i servizi in maniera congiunta: analysis services, notification services, …

Mirroring del database

Questa nuova funzionalità, a metà strada tra il clustering e il log shipping, è una soluzione prettamente software in grado di aumentare la disponibilità di database con un failover quasi istantaneo consentendo di mantenere una copia di un database tra un server primario e uno secondario.

Permette anche la configurazione di un terzo server, il Witness, in grado di tenere monitorato il principal e di effettuare un failover (promuovere il secondario al ruolo di primario) nel caso in cui dovesse cadere (guasto, problema, …).

Disponibile in modalità sincrona (“high protection mode”, oppure “high availability mode” con il Witness: quando e solo quando il secondo server esegue il commit della transazione il client riceve la notifica di termine transazione) o in modalità asincrona (“high performance mode”, non implementabile con la versione standard di SQL Server 2005: il client riceve la notifica di termine transazione quando i dati sono scritti sul db principal) consente di aumentare in maniera significativa la disponibilità di un database).

A differenza di un sistema cluster non richiede hardware specifico, né richiede un intervento manuale come il log shipping.

Il Management studio fornisce un comodo wizard in grado di configurare in maniera opportuna la macchina Principal (chi ha i dati e vuole che vengano tenuti allineati), la macchina Mirror (chi terrà la copia delle informazioni) ed eventualmente la macchina Witness che, potendola far fare a un’istanza SQL Express, ha un costo nullo sul sistema.

Log shpping

Valido ed economico strumento, alternativo al clustering, in grado di fornire protezione dei nostri dati utilizzando il transaction log per monitorare i cambiamenti.

È un metodo automatico per mantenere standby server, interamente basato sulla solida architettura di backup e restore di sql server.

Attori di questa architettura sono un primary server (istanza che contiene il db), uno standby server (contiene una copia del db di produzione e può essere messo in linea per rimpiazzare il primary. Può contenere db provenienti da differenti primary servers) ed eventualmente un server di monitorino (monitora lo stato dei job di log shipping sia sui primary che sui server di standby).

L’attenzione maggiore, con questa tecnologia, sarà rivolta verso tutti quegli oggetti (server logins, jobs, alert, packages ssis, …) che dovranno, necessariamente, essere copiati (o ricreati) con una differente modalità in quanto il log shipping, lavorando a livello database non effettua nessun monitorino su oggetti del database Master o/o Msdb e/o su file system.

Ricordiamo che questa funzionalità è disponibile solo per i database utente e non per i database di sistema.

Replica

Presenti dalla versione 6.0, sono una soluzione ideale per necessità di distribuzione dei dati, aggregare dati provenienti dalla periferia o semplicemente per ottenere disponibilità in tempo reale si basa su un modello di pubblicazione / sottoscrizione consentendo a un server primario di distribuire dati verso uno o più server secondari.

SQL Server fornisce diverse tipologie di replica:

  • Snapshot: distribuisce i dati così come appaiono in un determinato momento (snapshots point in time dei dati). È una “foto” che viene passata (dati e schema) ai sottoscrittori. Tutte le tipologie di replica utilizzano questa modalità per generare gli snapshot iniziali. Ottimo quando si hanno molti dati che vengono modificati in una volta sola in maniera poco frequente

  • Transazionale: le modifiche ai dati vengono applicate ai sottoscrittori nello stesso ordine e negli stessi limiti della transazione con cui vengono eseguite nel server di pubblicazione. Il “log reader” legge le transazioni marcate per la replica nel transaction log, copia le transazioni del database di distribuzione (distribution) che le copierà nei sottoscrittori (latenza minima)

  • Merge: modifiche dei dati e dello schema apportate successivamente nel server di pubblicazione e nei sottoscrittori vengono rilevate tramite trigger. Consente di lavorare su tutti i db in modo autonomo e unire gli aggiornamenti. Costruita per client che sono offline di frequente, è in grado di tracciare tutti i cambiamenti, risolvere e tenere traccia dei conflitti, utilizza poche risorse e poca banda

  • Eterogenea: consente di pubblicare tabelle Oracle per la replica inserendo opportuni trigger sulle stesse. È disponibile solo in modalità unidirezionale da Oracle verso SQL Server (no loopback) solo con la versione Enterprise.

SQL - Fig 3

EE = SQL Server 2005 Enterprise Edition
DE = SQL Server 2005 Developer Edition
SE = SQL Server 2005 Standard Edition
WG = SQL Server 2005 Workgroup Edition
SSE = SQL Server 2005 Express Edition
SSEA = SQL Server 2005 Express Edition with Advanced Services

1) WG come Publisher: support per 25 subscriptions verso merge publications e 5 subscriptions verso transactional publications. Supporto illimitato verso snapshot publications.

2) SSE: impossibile da configurare come Publisher o Distributor. SSE può essere Subscriber

3) SSE può essere Subscriber

4) Supporto 32-bit e 64-bit

La scelta di una soluzione appropriata

La scelta dello strumento più appropriato dipende sicuramente da diverse considerazioni che potremmo elencare tra:

  • Failover automatico

  • Nessuna perdita di dati

  • Trasparenza verso il client

  • Granularità a livello di istanza o database

Chiaramente durante la scelta dello strumento che riterremo più appropriato possiamo tenere conto anche della possibilità di combinazione tra le varie tecnologie. Ad esempio potrei utilizzare una replica dei miei dati su database che sono comunque mirrorati, oppure avere un sistema di log shipping su macchine in cluster.


Mostra:
© 2014 Microsoft