Panoramica delle soluzioni a disponibilità elevata

In questa sezione vengono presentate alcune soluzioni a disponibilità elevata di SQL Server che consentono di migliorare la disponibilità di server o database. Una soluzione a disponibilità elevata maschera gli effetti di un malfunzionamento hardware o software e mantiene la disponibilità delle applicazioni in modo che il tempo di inattività percepito dagli utenti sia ridotto al minimo.

SQL Server offre varie opzioni per la disponibilità elevata per un server o un database. Le opzioni a disponibilità elevata sono le seguenti:

• Clustering di failover

  Il clustering di failover offre un supporto a disponibilità elevata per un'istanza completa di SQL Server. Un cluster di failover è una combinazione di uno o più nodi, o server, con due o più dischi condivisi. Le applicazioni vengono installate ognuna in un gruppo cluster di Microsoft Cluster Service (MSCS), noto come gruppo di risorse. In qualsiasi momento, ogni gruppo di risorse appartiene a un solo nodo del cluster. Il servizio applicazione dispone di un nome virtuale indipendente dai nomi dei nodi e viene definito nome dell'istanza del cluster di failover. Un'applicazione può connettersi all'istanza del cluster di failover facendo riferimento al nome dell'istanza del cluster di failover. Non è necessario che l'applicazione sappia quale nodo ospita l'istanza del cluster di failover.

  Un'istanza del cluster di failover di SQL Server viene visualizzato sulla rete come un singolo computer, tuttavia dispone di funzionalità per il failover da un nodo a un altro qualora il nodo corrente diventi non disponibile. Ad esempio, nel caso di malfunzionamento hardware che non sia relativo a un disco, di blocco o di aggiornamenti pianificati del sistema operativo, è possibile configurare un'istanza di SQL Server su un nodo di un cluster di failover in modo che esegua il failover su qualsiasi altro nodo del gruppo di dischi.

  Un cluster di failover non costituisce una protezione contro i malfunzionamenti del disco. È possibile utilizzare il clustering di failover per ridurre i periodi di inattività del sistema e ottenere una maggiore disponibilità delle applicazioni. Il clustering di failover è supportato in SQL Server Enterprise e in SQL Server Developer e, con alcune restrizioni, in SQL Server Standard. Per ulteriori informazioni sul clustering di failover, vedere Introduzione al clustering di failover di SQL Server 2008 e Installazione di un cluster di failover di SQL Server 2008.

• Mirroring del database

  Il mirroring del database è essenzialmente una soluzione software per aumentare la disponibilità del database supportando un failover quasi istantaneo. Il mirroring del database è utilizzabile per gestire un singolo database di standby, oppure un database mirror, per un database di produzione corrispondente detto database principale.

  Il database mirror viene creato ripristinando un backup del database principale senza recupero. Ciò rende il database mirror inaccessibile ai client. È tuttavia possibile utilizzarlo in modo indiretto per la generazione di report tramite la creazione di uno snapshot del database nel database mirror. Lo snapshot del database offre ai client un accesso di sola lettura ai dati del database così com'era al momento della creazione dello snapshot.

  Ogni configurazione del mirroring del database implica un server principale contenente il database principale e un server mirror contenente il database mirror. Il server mirror mantiene continuamente aggiornato il database mirror rispetto al database principale.

  Il mirroring del database viene eseguito con il funzionamento sincrono in modalità a sicurezza elevata o con il funzionamento asincrono in modalità a prestazioni elevate. In modalità a prestazioni elevate, il commit delle transazioni viene eseguito senza attendere che il server mirror salvi il log su disco, ottimizzando così le prestazioni. In modalità a sicurezza elevata, il commit di una transazione viene eseguito su entrambi i partner, ma con il rischio di aumentare la latenza delle transazioni.

  Nella configurazione più semplice, il mirroring del database riguarda solo il server principale e il server mirror. In questa configurazione, qualora il server principale vada perso, è possibile utilizzare il server mirror come server di standby a caldo, con una possibile perdita di dati. Nella modalità a sicurezza elevata è supportata una configurazione alternativa, ovvero la modalità a sicurezza elevata con failover automatico. Questa configurazione implica un'istanza di un terzo server, detto server di controllo del mirroring, che consente al server mirror di agire come server di standby a caldo. Il failover dal database principale al database mirror richiede in genere alcuni secondi.

  A partire da SQL Server 2005 Service Pack 1 (SP1), i partner e i server di controllo del mirroring del database sono supportati in SQL Server Standard Edition e SQL Server Enterprise Edition. Mentre i partner devono utilizzare la stessa edizione e il mirroring del database asincrono (modalità a elevate prestazioni) è supportato solo da SQL Server Enterprise, i server di controllo sono supportati anche in SQL Server Workgroup Edition e SQL Server Express.

  Per ulteriori informazioni sul mirroring del database, vedere Mirroring del database.

• Log shipping

  Analogamente al mirroring del database, il log shipping opera a livello di database. È possibile utilizzare il log shipping per gestire uno o più database in modalità warm standby per un database di produzione corrispondente denominato database primario. I database in modalità standby sono anche denominati database secondari. Ogni database secondario viene creato ripristinando un backup del database principale senza recupero o con standby. Il ripristino con standby consente di utilizzare il database secondario risultante per la generazione limitata di report.

  Una configurazione di log shipping include un singolo server primario contenente il database primario, uno o più server secondari, ognuno con un database secondario, e un server di monitoraggio. Ogni server secondario aggiorna il proprio database secondario a intervalli impostati dai backup dei log del database primario. Il log shipping implica un ritardo modificabile dall'utente tra il momento in cui il server primario crea un backup dei log del database primario e il momento in cui il server secondario ripristina il backup dei log. Prima che il failover possa avere luogo, è necessario aggiornare completamente un database secondario applicando manualmente gli eventuali backup dei log non ripristinati.

  Il log shipping offre la flessibilità derivante dal supporto di più database standby. Se sono necessari più database di standby, è possibile utilizzare il log shipping in modo autonomo o a integrazione del mirroring del database. Quando queste soluzioni sono utilizzate insieme, il database principale corrente della configurazione del mirroring del database rappresenta anche il database primario corrente della configurazione per il log shipping.

  Il log shipping è supportato nelle edizioni Enterprise, Standard e Workgroup di SQL Server. Per ulteriori informazioni sul log shipping, vedere Panoramica del log shipping e Amministrazione del log shipping.

• Replica

  La replica utilizza un modello di pubblicazione/sottoscrizione. Tale modello consente a un server primario, denominato server di pubblicazione, di distribuire dati a uno o più server secondari, denominati Sottoscrittori. La replica consente disponibilità in tempo reale e scalabilità tra tali server. La replica supporta i filtri per fornire un subset di dati nei Sottoscrittori e consente inoltre aggiornamenti partizionati. I Sottoscrittori sono in linea e disponibili per la generazione di report o per altre funzioni, senza recupero delle query. SQL Server offre tre tipi di replica: snapshot, transazionale e di tipo merge. La replica transazionale determina la latenza minima e viene in genere utilizzata per la disponibilità elevata. Per ulteriori informazioni, vedere Incremento di scalabilità e disponibilità.

  La replica è supportata in tutte le edizioni di SQL Server. La pubblicazione della replica non è disponibile con SQL Server Express o SQL Server Compact 3.5 SP1.

  Importante
  Una strategia di backup e ripristino ben progettata e implementata è importante per qualsiasi soluzione a disponibilità elevata. Per ulteriori informazioni, vedere Backup e ripristino di database in SQL Server e Backup e ripristino dei database replicati.

• Database condivisi scalabili

  La funzionalità relativa ai database condivisi scalabili consente di implementare la scalabilità orizzontale per un database di sola lettura creato esclusivamente per la generazione di report. Il database di report deve risiedere in un set di volumi dedicati di sola lettura, principalmente destinati a ospitare il database. Grazie all'utilizzo di hardware apposito per server e volumi, è possibile implementare la scalabilità orizzontale per un database di report che consente di visualizzare nello stesso modo i dati dei report in più server di report. Questa funzionalità consente inoltre di eseguire in modo semplice il processo di aggiornamento del database di report. Per ulteriori informazioni, vedere Panoramica dei database condivisi scalabili.