Riepilogo: le istanze del cluster di failover e i gruppi di disponibilità
annuncio pubblicitario
Guida all'architettura AlwaysOn: creazione di una soluzione per disponibilità elevata e ripristino di emergenza con istanze del cluster di failover e gruppi di disponibilità Articolo tecnico su SQL Server Autori: Joseph Sack (SQLskills.com), Sanjay Mishra (Microsoft) Revisori tecnici: Min He (Microsoft), Chuck Heinzelman (Microsoft), Alexi Khalyako (Microsoft), Charles Mathews (Microsoft), Prem Mehra (Microsoft), Juergen Thomas (Microsoft), Mike Weiner (Microsoft), Amitabh Tamhane (Microsoft), Brent Ozar (Brent Ozar PLF), Gianluca Hotz (SolidQ), David P. Smith (ServiceU), Michael Steineke (Edgenet), Glenn Berry (SQLskills.com) Content Program Manager: Glenn Minch (Microsoft) Data di pubblicazione: giugno 2012 Contesto di applicazione: SQL Server 2012 Riepilogo: le istanze del cluster di failover e i gruppi di disponibilità di SQL Server 2012 AlwaysOn forniscono una soluzione completa per la disponibilità elevata e il ripristino di emergenza. Prima di SQL Server 2012, molti clienti utilizzavano le istanze del cluster di failover per assicurare elevata disponibilità locale all'interno di un data center e il mirroring del database per il ripristino di emergenza in un data center remoto. Con SQL Server 2012 è possibile sostituire questo modello di progettazione con un'architettura basata sulle istanze del cluster di failover per assicurare disponibilità elevata e i gruppi di disponibilità per soddisfare le esigenze aziendali di ripristino di emergenza. I gruppi di disponibilità sfruttano la tecnologia Windows Server Failover Clustering (WSFC) e includono molte funzionalità non disponibili nel mirroring del database. In questo documento verranno trattati in dettaglio i requisiti fondamentali della topologia di questo specifico modello di progettazione, con particolare attenzione alle considerazioni sull'archiviazione asimmetrica, la scelta del modello di quorum, i voti del quorum, i passaggi necessari per creare l'ambiente e un flusso di lavoro in cui viene illustrata la ripartizione della gestione di un evento di ripristino di emergenza nella nuova topologia tra i diversi ruoli partecipanti. Copyright Il documento viene fornito “com'è”. Le informazioni e le opinioni espresse nel presente documento, inclusi gli URL e altri riferimenti a siti Web, possono essere soggette a modifiche senza preavviso. L'utente accetta di utilizzarlo a proprio rischio. Alcuni esempi utilizzati in questo documento vengono forniti a scopo puramente illustrativo e sono fittizi. Nessuna associazione reale o connessione è intenzionale o può essere desunta. Il presente documento non implica la concessione di alcun diritto di proprietà intellettuale relativo ai prodotti Microsoft. È possibile copiare e utilizzare questo documento per fini di riferimento interno. © 2012 Microsoft. Tutti i diritti sono riservati. 2 Sommario Introduzione.................................................................................................................................................. 4 Istanze del cluster di failover per HA e mirroring del database per DR........................................................ 4 Istanze del cluster di failover per HA locale e gruppi di disponibilità per DR ............................................... 5 Pianificazione e considerazioni ..................................................................................................................... 7 Requisiti WSFC .......................................................................................................................................... 7 Archiviazione asimmetrica ........................................................................................................................ 7 Denominazione e percorso di file delle istanze ........................................................................................ 7 Modalità di disponibilità e modalità di failover ........................................................................................ 8 Modello di quorum e voti dei nodi ........................................................................................................... 8 Strumenti per visualizzare e modificare il modello di quorum e i voti dei nodi ................................. 11 Configurazione del modello di quorum WSFC .................................................................................... 11 Utilizzo delle DMV e del dashboard AlwaysOn per visualizzare le informazioni sul quorum............. 12 Configurazione dei voti dei nodi ......................................................................................................... 13 Connettività dei client ............................................................................................................................. 14 Carichi di lavoro di lettura/scrittura ................................................................................................... 14 Carichi di lavoro di sola lettura ........................................................................................................... 14 Supporto per la connessione a più subnet ......................................................................................... 15 Configurazione della soluzione FCI+AG ...................................................................................................... 15 Prerequisiti di installazione ..................................................................................................................... 15 Configurazione della soluzione nel data center primario ....................................................................... 16 Configurazione della soluzione nel data center di DR ............................................................................ 21 Considerazioni sul monitoraggio ................................................................................................................ 26 Ripristino in seguito a un'emergenza ......................................................................................................... 27 Ripristino del data center primario ............................................................................................................. 33 Conclusione ................................................................................................................................................. 38 Riferimenti .................................................................................................................................................. 38 3 Introduzione Microsoft SQL Server 2012 AlwaysOn offre opzioni di progettazione flessibili per realizzare la soluzione per la disponibilità elevata (HA, High Availability) e il ripristino di emergenza (DR, Disaster Recovery) più adeguata alle proprie esigenze. Per ulteriori informazioni sulle scelte disponibili, vedere il post sui modelli di progettazione per la disponibilità elevata e il ripristino di emergenza di SQL Server 2012 AlwaysOn. In questo white paper viene descritta una soluzione che utilizza le istanze del cluster di failover (FCI, Failover Cluster Instance) per la disponibilità elevata e i gruppi di disponibilità (AG, Availability Group) per il ripristino di emergenza. Questa architettura combina una soluzione di archiviazione condivisa (FCI) e una soluzione di archiviazione non condivisa (AG). Prima di SQL Server 2012, un'architettura di distribuzione per HA e DR richiedeva normalmente l'uso delle istanze del cluster di failover per la disponibilità elevata locale e il mirroring del database (DBM, Database Mirroring) per il ripristino di emergenza remoto. Con SQL Server 2012 i gruppi di disponibilità possono sostituire la componente di mirroring del database della soluzione. Questo documento contiene alcune considerazioni sulla pianificazione e la descrizione dettagliata della procedura di creazione di questa soluzione. Vengono inoltre illustrati i passaggi necessari per il ripristino in seguito a una situazione di emergenza e le modalità per tornare al data center primario dopo tale operazione. Gli argomenti trattati in questo documento presuppongono una conoscenza di base dei concetti di istanza del cluster di failover, gruppo di disponibilità, disponibilità elevata e ripristino di emergenza. Per ulteriori informazioni sulla serie completa di funzionalità delle soluzioni AlwaysOn, vedere il white paper Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza. Per ulteriori informazioni sui passaggi relativi alla migrazione, vedere il white paper Guida alla migrazione: migrazione al clustering di failover e ai gruppi di disponibilità di SQL Server 2012 da distribuzioni precedenti basate su clustering e mirroring. Il white paper è destinato agli amministratori di database e agli architetti della tecnologia SQL Server, nonché agli amministratori di sistema che collaborano con il ruolo di amministratore di database per gestire Windows Server, Servizi di dominio Active Directory, WSFC e i servizi di rete. Istanze del cluster di failover per HA e mirroring del database per DR Come già detto nell'introduzione, prima di SQL Server 2012 un'architettura di distribuzione di SQL Server richiedeva normalmente l'uso delle istanze del cluster di failover per la disponibilità elevata locale e del mirroring del database per il ripristino di emergenza tra data center. Questa soluzione è stata definita FCI+DBM. In questo tipo di soluzione, viene configurata un'istanza del cluster di failover nel data center primario utilizzando l'archiviazione su disco condivisa (ad esempio tramite rete SAN) per assicurare protezione a livello di istanza di SQL Server. Se si verifica un errore hardware su uno dei nodi, un altro nodo può assumere il ruolo di host dell'istanza del cluster di failover all'interno dello stesso data center. Tra il sito primario e il sito di ripristino di emergenza viene utilizzato il mirroring del database per assicurare protezione a livello di database. In caso di interruzione del data center primario o di errore delle risorse di archiviazione condivisa nel data center primario, è possibile utilizzare il mirror nel data center di ripristino di emergenza (DR) per ripristinare il servizio alle applicazioni. Nel data center di DR viene ospitata un'altra istanza del cluster di failover su un cluster WSFC separato, con risorse di archiviazione condivisa proprie. L'architettura di questa soluzione è illustrata nella Figura 1. 4 Data center primario Data center di ripristino di emergenza Cluster Cluster WSFC WSFC "B" "A" Cluster WSFC "A" SQLFCIPrimary\INST_A SQLFCIDR\INST_A Mirroring del database Database principale Database mirror Figura 1: istanza del cluster di failover per la disponibilità elevata e mirroring del database per il ripristino di emergenza In genere il data center di DR è situato a una certa distanza dal data center primario e la sessione di mirroring è impostata sulla modalità asincrona a prestazioni elevate per ridurre al minimo l'overhead delle transazioni. In alcuni casi viene anche utilizzato il mirroring del database sincrono tra i data center. Per ulteriori informazioni, incluso un esempio pratico di questa specifica soluzione, vedere Disponibilità elevata e ripristino di emergenza in ServiceU: case study tecnico su SQL Server 2008. Istanze del cluster di failover per HA locale e gruppi di disponibilità per DR Con SQL Server 2012 una soluzione simile comporta l'utilizzo delle istanze del cluster di failover per la disponibilità elevata locale, come nella soluzione FCI+DBM, ma utilizzando i gruppi di disponibilità per il ripristino di emergenza. Questa soluzione è definita FCI+AG. La Figura 2 mostra la soluzione con le istanze del cluster di failover per la disponibilità elevata locale e i gruppi di disponibilità per il ripristino di emergenza tra data center. Figura 2: istanze del cluster di failover per la disponibilità elevata e gruppi di disponibilità per il ripristino di emergenza La Figura 2 mostra due istanze del cluster di failover, una nel data center primario e l'altra nel data center di ripristino di emergenza. Ciascuna istanza include due nodi e risorse di archiviazione condivisa proprie. Tutti e quattro i nodi, tuttavia, fanno parte dello stesso cluster WSFC. L'appartenenza di tutti i nodi allo stesso cluster WSFC è un requisito per i gruppi di disponibilità. 5 La topologia illustrata nella Figura 2 corrisponde a uno scenario semplice con due data center, in ciascuno dei quali è ospitata una replica del gruppo di disponibilità su un'istanza del cluster di failover con due nodi. L'architettura consente variazioni a questa topologia: Più data center Più repliche: fino a cinque, inclusa una replica primaria e da una a quattro repliche secondarie Più di due nodi in ogni istanza del cluster di failover se si desidera aggiungere nodi passivi a scopo di HA Non tutte le repliche in un gruppo di disponibilità devono trovarsi su istanze del cluster di failover; alcune possono trovarsi su istanze di SQL Server autonome e non del cluster di failover Più gruppi di disponibilità basati sul raggruppamento logico di database per l'ambiente applicativo Benché gli argomenti trattati in questo white paper siano incentrati sulla topologia mostrata nella Figura 2, i concetti generali si applicano anche ad altre variazioni. Poiché i quattro nodi dei due siti fanno parte dello stesso cluster WSFC, è necessario considerare alcuni aspetti aggiuntivi riguardanti l'utilizzo delle risorse di archiviazione condivisa visibili solo ai nodi del data center locale. Ulteriori considerazioni vanno dedicate ai voti del quorum e al modello di quorum. Il documento tratterà questo e altri aspetti. È possibile configurare il gruppo di disponibilità con uno o più database utente e impostarlo sullo spostamento sincrono o asincrono dei dati. Le repliche sincrone aggiungono latenza alle transazioni del database perché, prima di eseguire il commit di una transazione, la replica primaria deve ricevere la conferma che i record del log sono stati finalizzati nei log delle repliche secondarie. È anche importante notare che l'istanza di SQL Server di ripristino di emergenza non deve necessariamente essere un'istanza del cluster di failover. Un gruppo di disponibilità potrebbe includere anche un'istanza di SQL Server autonoma per la replica secondaria. Con i gruppi di disponibilità, è possibile combinare istanze autonome e istanze del cluster di failover in una sola topologia sullo stesso cluster WSFC. Nella Figura 3 viene illustrata una topologia mista. Data center primario Data center di ripristino di emergenza Cluster WSFC (Windows Server Failover Clustering) SQLFCIPrimary\INST_A SQLDR\INST_B Gruppo di disponibilità Database primari Database secondari Figura 3: istanza del cluster di failover per HA e gruppi di disponibilità per DR, con un'istanza autonoma con la funzione di istanza di DR La parte restante del documento si basa sul presupposto che la replica primaria e le repliche secondarie siano tutte istanze del cluster di failover ospitate e non istanze autonome. 6 Pianificazione e considerazioni In questa sezione vengono trattati in dettaglio i requisiti, i prerequisiti e alcune considerazioni relative alla pianificazione di cui tenere conto prima di implementare una soluzione FCI+AG per la disponibilità elevata e il ripristino di emergenza. Requisiti WSFC Una differenza fondamentale tra una soluzione FCI+DBM e una soluzione FCI+AG è che nella prima si utilizzano due istanze del cluster di failover in due cluster WSFC separati, mentre nella seconda le due istanze del cluster di failover si trovano in un unico cluster WSFC. Tutte le repliche di un gruppo di disponibilità devono trovarsi in un unico cluster WSFC all'interno di un singolo dominio Active Directory, anche tra data center. Archiviazione asimmetrica In presenza di due istanze del cluster di failover, una in ciascun sito del cluster WSFC multisito, è necessario valutare in che modo gestire l'archiviazione condivisa. Ciascuna istanza del cluster di failover dispone delle proprie risorse di archiviazione condivisa. I nodi nel sito primario condividono le risorse di archiviazione tra loro per formare un'istanza del cluster di failover con archiviazione condivisa; analogamente, i nodi nel sito di DR condividono le risorse di archiviazione fra loro per formare un'altra istanza del cluster di failover con archiviazione condivisa. Le risorse di archiviazione nel sito primario non sono visibili ai nodi nel sito di ripristino di emergenza e viceversa. Questa organizzazione delle risorse di archiviazione, in cui un disco del cluster è condiviso tra un subset di nodi all'interno di un cluster WSFC, viene definita archiviazione asimmetrica. Prima dell'introduzione della funzionalità di archiviazione asimmetrica, le risorse di archiviazione condivisa dovevano essere visibili a tutti i nodi del cluster WSFC (archiviazione simmetrica). L'archiviazione asimmetrica è stata introdotta come opzione di distribuzione per Windows Server 2008 tramite un hotfix. È supportata anche in Windows Server 2008 R2 tramite Service Pack 1. Per ulteriori informazioni, vedere l'articolo della Knowledge Base sull'hotfix per aggiungere supporto per le archiviazioni asimmetriche allo snap-in MMC Gestione cluster di failover per un cluster di failover che esegue Windows Server 2008 o Windows Server 2008 R2. Questo miglioramento di Windows Server è l'elemento chiave che rende possibile l'architettura FCI+AG descritta in questo white paper. Questa funzionalità consente infatti di combinare la soluzione di archiviazione condivisa (istanze del cluster di failover) e la soluzione di archiviazione non condivisa (gruppi di disponibilità) in un'unica soluzione per HA+DR. Di conseguenza, consente anche di utilizzare lettere di unità identiche per le risorse disco condivise tra data center. Notare che quando si configura l'archiviazione asimmetrica, durante i test di convalida del cluster WSFC potrebbe apparire il messaggio “Il disco con ID XYZ è visibile o impostabile come disco di tipo cluster solo da un sottoinsieme di nodi”. Per l'archiviazione asimmetrica si tratta di un comportamento previsto e non indica la presenza di problemi. Denominazione e percorso di file delle istanze Le due istanze del cluster di failover devono utilizzare nomi diversi all'interno dello stesso cluster WSFC, ad esempio “INST_A” come nome dell'istanza del cluster di failover primaria e ”INST_B” come nome dell'istanza del cluster di failover di DR. Contrariamente ai gruppi di disponibilità, il mirroring del database consente a ogni istanza del cluster di failover di utilizzare lo stesso nome se le istanze si trovano in cluster WSFC separati. Nella Figura 1, che rappresenta la soluzione FCI+DBM, le due istanze del cluster di failover hanno lo stesso nome, INST_A. 7 Ogni istanza del cluster di failover ha risorse di archiviazione condivisa proprie che non sono accessibili ai nodi presenti nell'altro data center. È opportuno utilizzare lettere di unità identiche per i dischi e percorsi identici per i file di database e i log delle transazioni di entrambe le istanze. Benché non si tratti di un requisito obbligatorio, se i percorsi di file differiscono sarà necessario eseguire un'azione RESTORE WITH MOVE manuale nel momento del ripristino dei database di replica sulla replica secondaria. Inoltre, percorsi eterogenei nelle due istanze del cluster di failover invalideranno le successive operazioni di aggiunta di file, quali la creazione di gruppi di file o di file di dati o di log secondari. Per ulteriori informazioni, incluso uno scenario di risoluzione del problema, vedere Risolvere i problemi relativi a una operazione di aggiunta file non riuscita (Gruppi di disponibilità AlwaysOn). Modalità di disponibilità e modalità di failover Per il gruppo di disponibilità creato tra le due istanze del cluster di failover è possibile definire la modalità di disponibilità con commit sincrono o asincrono. Se la modalità di disponibilità è sincrona, la replica primaria attende che le transazioni utente siano state inviate e finalizzate nelle repliche secondarie prima di eseguirne il commit. Questo meccanismo può comportare l'aggiunta di latenza alle transazioni utente, ma riduce la possibilità di perdita dei dati nella replica secondaria facendo sì che le transazioni vengano inviate all'istanza del cluster di failover di ripristino di emergenza prima che venga segnalato un commit sulla transazione della replica primaria. Se la modalità di disponibilità è asincrona, la replica primaria esegue il commit delle transazioni utente senza attendere la finalizzazione delle transazioni nei log delle repliche secondarie. In tal modo viene ridotta la latenza delle transazioni, ma aumenta il rischio di perdita di dati nell'eventualità di un'interruzione. Per quanto riguarda le modalità di failover, quando le istanze del cluster di failover vengono utilizzate nella topologia con i gruppi di disponibilità, la modalità di failover dei gruppi di disponibilità deve essere manuale (non automatica). Tuttavia, all'interno di ogni istanza del cluster di failover, il failover dell'istanza di SQL Server sugli altri nodi è automatico. Modello di quorum e voti dei nodi Nota: la trattazione sui modelli di quorum e le informazioni correlate in questo white paper si riferiscono alle soluzioni in esecuzione sui sistemi operativi Windows Server 2008 e Windows Server 2008 R2, con gli appropriati Service Pack e aggiornamenti software. Poiché l'infrastruttura alla base della soluzione FCI+AG è un cluster WSFC, è importante valutare il modello di quorum appropriato. La configurazione del quorum è gestita a livello di WSFC, indipendentemente dal numero di istanze del cluster di failover, dal numero di repliche e dal numero di gruppi di disponibilità ospitati nel cluster WSFC. In WSFC sono disponibili quattro modelli di quorum: Maggioranza dei nodi, Maggioranza dei nodi e delle condivisioni file, Maggioranza dei nodi e dei dischi, Nessuna maggioranza: Solo disco. Per ulteriori informazioni sui modelli di quorum, vedere la sezione della guida dettagliata ai cluster di failover relativa alla configurazione del quorum in un cluster di failover. 8 Prima di selezionare un modello di quorum è importante prendere in considerazione il numero di nodi votanti. L'assegnazione dei voti ai nodi appropriati svolge un ruolo importante nella progettazione HA+DR. Benché per impostazione predefinita ogni nodo in un cluster di failover possieda un voto, questa configurazione potrebbe non essere adeguata a una specifica soluzione per HA+DR, a seconda della distribuzione dei nodi nel data center primario e nel data center di ripristino di emergenza. È disponibile un hotfix (http://support.microsoft.com/kb/2494036) che consente di assegnare 1 voto ad alcuni nodi e 0 voti ad altri nel cluster WSFC. La proprietà NodeWeight del nodo WSFC rappresenta il voto per quel particolare nodo. Il valore “0” indica che il nodo non ha voti. Il valore “1” indica che il nodo dispone di un voto di quorum. Questo hotfix deve essere installato in ogni nodo nella topologia. Suggerimenti di carattere generale per i voti del quorum relativi a una soluzione AlwaysOn per HA+DR vengono forniti nell'argomento Modifiche consigliate ai voti quorum nella documentazione online di SQL Server. Tali suggerimenti vanno considerati come linee guida per definire lo schema di voto della soluzione AlwaysOn. In base a queste linee guida, per evitare che il quorum dei nodi nel data center primario venga compromesso da interruzioni nel data center di DR o dalla perdita di connettività tra i due data center, lo schema di voto per la soluzione FCI+AG presentata nella Figura 2 sarà: 1 voto per ogni nodo nel data center primario 0 voti per ogni nodo nel data center di ripristino di emergenza Questa assegnazione di voti si traduce in un totale di 2 voti per il cluster WSFC. In base alla procedura consigliata il numero totale di voti per il cluster WSFC dovrebbe essere un numero dispari. In presenza di un numero pari di nodi votanti (come nella topologia di esempio), valutare l'aggiunta di una condivisione file di controllo, quindi scegliere il modello di quorum Maggioranza dei nodi e delle condivisioni file. Nota: in molti ambienti aziendali la condivisione file è spesso di proprietà di un team diverso, che si occupa anche della sua gestione. In questo caso il team controlla il voto di un nodo e quindi ha influenza sullo stato del cluster di failover. Una condivisione file diventa un voto e deve pertanto essere sempre disponibile. Per assicurare la disponibilità del voto della condivisione file, si consiglia di utilizzare funzionalità di clustering o altre tecnologie di HA. In alternativa, è possibile aggiungere un altro nodo e utilizzare il modello di quorum Maggioranza dei nodi. Il nodo aggiuntivo deve trovarsi all'interno del cluster WSFC ma non deve necessariamente fare parte della configurazione delle istanze del cluster di failover. Deve inoltre essere situato nello stesso data center primario, insieme agli altri due nodi WSFC presenti nel data center. Nella Figura 4 viene mostrata l'allocazione dei voti basata sul modello di quorum Maggioranza dei nodi e delle condivisioni file. 9 Figura 4: soluzione FCI+AG per HA/DR con assegnazione dei voti ai nodi Nella Figura 4 ciascuno dei due nodi nel data center primario possiede un voto. Nel data center primario è definita anche una condivisione file di controllo, che possiede anch'essa un voto. I due nodi nel data center di ripristino di emergenza non possiedono voti e non possono influire sul quorum. Gli altri possibili modelli di quorum selezionabili per questa architettura di distribuzione sono Maggioranza dei nodi e dei dischi (con un disco asimmetrico) o Nessuna maggioranza: Solo disco (con un disco asimmetrico). Prima che l'archiviazione asimmetrica fosse disponibile per i cluster WSFC, un disco condiviso poteva fungere da risorsa di quorum se visibile a tutti i nodi WSFC. Con l'archiviazione asimmetrica, le risorse di archiviazione del cluster possono essere visibili a un subset di nodi ed essere comunque utilizzate come risorsa quorum. Con il modello di quorum asimmetrico Nessuna maggioranza: Solo disco, è possibile implementare uno scenario di tipo “ultimo rimasto”, in cui il cluster WSFC mantiene il quorum purché un singolo nodo abbia contatto con il disco asimmetrico che funge da risorsa quorum. È possibile abilitare questa configurazione utilizzando la riga di comando cluster.exe, ma non tramite Gestione cluster di failover o Windows PowerShell. Per un esempio di questa configurazione, vedere la sezione sulla modifica della configurazione del quorum in un cluster di failover con archiviazione asimmetrica nella sezione della guida dettagliata ai cluster di failover relativa alla configurazione del quorum in un cluster di failover. Importante: l'uso di un disco asimmetrico come risorsa quorum offre numerosi vantaggi, ma richiede anche un livello molto più alto di competenza sui cluster e di pianificazione. È necessario acquisire grande familiarità con questa configurazione prima di distribuirla in un ambiente di produzione. In caso di un'interruzione del data center primario che richieda l'attivazione del servizio nel data center di ripristino di emergenza, è necessario valutare nuovamente la configurazione del quorum. A ogni nodo nel data center di ripristino di emergenza deve essere assegnato un voto, mentre è necessario rimuovere il voto (impostandolo su “0”) di ogni nodo nel data center primario fino al ripristino del servizio. Presupponendo la presenza di due nodi nell'istanza del cluster di failover e un'interruzione di lunga durata del data center primario, è inoltre necessario configurare una condivisione file di controllo (o un altro tipo di voto aggiuntivo) nel data center di DR e impostare di conseguenza il modello di quorum. Quando il data center primario è pronto per tornare operativo, lo schema di voto deve essere nuovamente modificato e il modello di quorum nuovamente valutato. Più avanti in questo documento verrà descritto dettagliatamente uno scenario di ripristino di emergenza e il flusso di processi associato. 10 Nel modello di quorum e nelle assegnazioni dei voti illustrati nella Figura 4 si presuppone che la soluzione comprenda due repliche, una per ogni data center. Se sono presenti più data center e si prevede di includere una parte della soluzione in un terzo data center, le decisioni sul modello di quorum e le assegnazioni dei voti possono variare. Strumenti per visualizzare e modificare il modello di quorum e i voti dei nodi Sono disponibili più modalità per visualizzare e modificare il modello di quorum e/o i voti del quorum del cluster. Nella tabella seguente sono elencati i vari strumenti per queste attività. Per visualizzare il modello di quorum Gestione cluster di failover di Windows Windows PowerShell Cluster.exe DMV di SQL Server Dashboard AlwaysOn in SQL Server Management Studio Per modificare il modello di quorum Gestione cluster di failover di Windows Windows PowerShell Cluster.exe Nota: è possibile utilizzare solo Cluster.exe per impostare il modello di quorum su “Maggioranza dei nodi e dei dischi (asimmetrici)” o su “Nessuna maggioranza: Solo disco (asimmetrico)” Per visualizzare i voti dei nodi Per modificare i voti dei nodi Windows PowerShell Cluster.exe DMV di SQL Server Dashboard AlwaysOn Windows PowerShell Cluster.exe Configurazione del modello di quorum WSFC Di seguito sono disponibili alcuni esempi dell'utilizzo di Windows PowerShell tramite riga di comando per visualizzare l'attuale modello di quorum e modificarlo. Per visualizzare il modello di quorum esistente Get-ClusterQuorum Per impostare il modello di quorum Maggioranza dei nodi Set-ClusterQuorum -NodeMajority Per impostare il modello di quorum su Maggioranza dei nodi e delle condivisioni file Set-ClusterQuorum -NodeAndFileShareMajority \\FileShare\Witness La condivisione file di controllo scelta non deve trovarsi su un nodo che fa già parte della configurazione WSFC AlwaysOn, ma può essere aggiunta come condivisione in un'altra configurazione WSFC e deve trovarsi all'interno dello stesso dominio Active Directory del cluster WSFC. Inoltre, l'account del servizio cluster WSFC deve disporre di autorizzazioni di lettura e scrittura per la condivisione file di controllo. Gestione cluster di failover include la logica per aggiungere queste autorizzazioni alla condivisione file di controllo, purché l'account utilizzato per modificare il modello di quorum disponga delle autorizzazioni per la condivisione file. 11 Utilizzo delle DMV e del dashboard AlwaysOn per visualizzare le informazioni sul quorum Non è possibile impostare o modificare il modello di quorum o i voti dei nodi tramite gli strumenti SQL Server, ma è possibile utilizzare query Transact-SQL sulle DMV e il dashboard AlwaysOn in SQL Server Management Studio per visualizzare i voti dei nodi e il modello di quorum del cluster di Windows che ospita il gruppo di disponibilità. Per visualizzare il modello di quorum del cluster di Windows che ospita il gruppo di disponibilità, eseguire una query sulla DMV sys.dm_hadr_cluster (http://technet.microsoft.com/it-it/library/hh212952(v=sql.110).aspx). SELECT FROM cluster_name, quorum_type_desc, quorum_state_desc sys.dm_hadr_cluster; Quando questa query viene eseguita nell'ambiente di esempio illustrato in questo white paper, restituisce il risultato seguente. cluster_name -----------contosocluster quorum_type_desc ---------------NODE_AND_FILE_SHARE_MAJORITY quorum_state_desc ----------------NORMAL_QUORUM Per visualizzare i voti dei nodi, eseguire una query sulla DMV sys.dm_hadr_cluster_members. SELECT FROM member_name, number_of_quorum_votes sys.dm_hadr_cluster_members; Quando questa query viene eseguita nell'ambiente di esempio illustrato in questo white paper, restituisce il risultato seguente (l'allocazione dei voti verrà trattata in una sezione successiva). member_name -----------------PrimaryNode1 PrimaryNode2 DRNode1 DRNode2 File Share Witness number_of_quorum_votes ---------------------1 1 0 0 1 È possibile utilizzare anche il dashboard AlwaysOn in SQL Server Management Studio per visualizzare i voti del quorum e lo stato del cluster. Nella Figura 5 vengono mostrate queste informazioni per un cluster di Windows con il modello di quorum Maggioranza dei nodi (lo stato del cluster e i voti del quorum sono evidenziati). 12 Figura 5: visualizzazione dei voti del quorum e dello stato del cluster nel dashboard AlwaysOn Anche se la colonna Voti del quorum non viene visualizzata per impostazione predefinita, è possibile aggiungerla al dashboard facendo clic con il pulsante destro del mouse sull'intestazione di colonna nella tabella Replica di disponibilità e selezionando la colonna da visualizzare. Per un modello di quorum Maggioranza dei nodi e delle condivisioni file, in questa vista del dashboard AlwaysOn vengono mostrati solo i nodi, non la condivisione file. Per visualizzare le informazioni complete sul quorum, fare clic su Visualizza informazioni sul quorum del cluster a destra. Verrà visualizzata una finestra popup simile a quella illustrata nella Figura 6. Figura 6: informazioni sul quorum del cluster per il modello di quorum Maggioranza dei nodi e delle condivisioni file Configurazione dei voti dei nodi La proprietà NodeWeight del nodo WSFC rappresenta il voto per quel particolare nodo. Negli esempi seguenti viene mostrato come configurare il nodo NodeWeight da un nodo in un cluster WSFC utilizzando Windows PowerShell. Per l'esecuzione di Windows PowerShell sul nodo server, fare clic su Start, scegliere Strumenti di amministrazione, quindi Moduli di Windows PowerShell. In questo esempio DRNode1 rappresenta un nodo WSFC specifico situato nel data center di ripristino di emergenza. 13 Per visualizzare le impostazioni di voto correnti per tutti i nodi Get-ClusterNode | fl NodeName, NodeWeight Per impostare il voto di un nodo su “0” (Get-ClusterNode “DRNode1”).NodeWeight=0 Nota: il valore “0” indica che il nodo non ha voti. Il valore “1” indica che il nodo dispone di un voto di quorum. Connettività dei client I metodi di connessione delle istanze del cluster di failover in SQL Server 2012 sono gli stessi delle versioni precedenti, ma per le migrazioni dal mirroring del database ai gruppi di disponibilità è necessario prendere in considerazione e pianificare alcune modifiche prima di poter utilizzare la nuova funzionalità delle repliche secondarie leggibili. Per ulteriori informazioni sulla migrazione, inclusi alcuni passaggi e considerazioni approfondite, vedere il white paper Guida alla migrazione: migrazione al clustering di failover e ai gruppi di disponibilità di SQL Server 2012 da distribuzioni precedenti basate su clustering e mirroring. Carichi di lavoro di lettura/scrittura Per i carichi di lavoro di lettura/scrittura eseguiti nei database di disponibilità in un gruppo di disponibilità, è possibile connettersi alla replica primaria utilizzando due opzioni. La prima opzione consiste nel connettersi direttamente al nome di rete virtuale (VNN) dell'istanza del cluster di failover, che è diverso per ogni replica. La seconda opzione consiste nell'utilizzare il nome del listener del gruppo di disponibilità. Questa è l'opzione preferita perché consente il reindirizzamento automatico e trasparente alla replica primaria corrente e consente di mantenere lo stesso nome nella stringa di connessione per tutte le istanze. Il listener del gruppo di disponibilità è un VNN che viene associato a uno o più indirizzi TCP/IP e porte di attesa e utilizzato per connettersi automaticamente a qualsiasi replica senza dover definire in modo esplicito ogni possibile replica del gruppo di disponibilità nella stringa di connessione. Se si esegue la migrazione delle connessioni dell'applicazione dei carichi di lavoro di lettura/scrittura da una soluzione basata sul mirroring del database che utilizza l'attributo Partner di failover, è comunque possibile continuare a utilizzare la stringa di connessione per il mirroring del database, ma solo se il gruppo di disponibilità viene configurato con una sola replica secondaria impostata per l'attività di lettura/scrittura. È quindi possibile utilizzare il nome server della replica primaria iniziale come origine dati e, facoltativamente, il nome della replica secondaria come partner di failover. Questa configurazione non va tuttavia utilizzata come soluzione a lungo termine. Carichi di lavoro di sola lettura Anche per le connessioni dei carichi di lavoro di sola lettura sono disponibili due opzioni. È possibile utilizzare il VNN dell'istanza del cluster di failover oppure il listener del gruppo di disponibilità e specificare il nuovo attributo ApplicationIntent nella stringa di connessione come “ReadOnly”. Se si utilizza una stringa di connessione per il mirroring del database legacy, è possibile connettersi al gruppo di disponibilità solo se questo viene impostato come singola replica secondaria configurata per l'attività di lettura/scrittura. 14 Se si desidera sfruttare il routing di sola lettura, è necessario utilizzare il nome del listener del gruppo di disponibilità insieme all'attributo ApplicationIntent e al valore “ReadOnly”. È inoltre necessario fare riferimento a un database di disponibilità all'interno del gruppo di disponibilità. Il gruppo di disponibilità deve essere configurato anche per il routing di sola lettura alle repliche secondarie leggibili tramite la creazione di URL di routing di sola lettura ed elenchi di routing di sola lettura. Per ulteriori informazioni su questo processo, vedere Configurare il routing di sola lettura per un gruppo di disponibilità (SQL Server). Supporto per la connessione a più subnet Il listener del gruppo di disponibilità può sfruttare anche l'attributo di connessione MultiSubnetFailover nelle librerie client. È consigliabile inserire nelle stringhe di connessione dei gruppi di disponibilità l'attributo MultiSubnetFailover per le topologie a più subnet che fanno riferimento a un nome di listener del gruppo di disponibilità. L'opzione di connessione MultiSubnetFailover abilita il supporto per le connessioni a più subnet e apre socket TCP per gli indirizzi IP del listener del gruppo di disponibilità in parallelo. Per le librerie client legacy che non supportano l'attributo MultiSubnetFailover, è necessario valutare la definizione di un appropriato timeout di accesso client. Per ulteriori informazioni sulla connettività dei client e il failover delle applicazioni, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server) nella documentazione online di SQL Server. Configurazione della soluzione FCI+AG In questo flusso di lavoro vengono descritti i passaggi necessari alla compilazione della soluzione FCI+AG. Benché in questa sede non vengano approfonditi tutti i dettagli, l'obiettivo è chiarire i passaggi di implementazione del flusso di lavoro e le attività di competenza di ciascun ruolo partecipante. Nei casi appropriati viene fatto riferimento alla documentazione di supporto. I passaggi sono suddivisi per ruolo perché la maggior parte degli ambienti delle grandi aziende prevede una separazione dei compiti tra i ruoli di amministratore del database, amministratore di Windows (o del cluster) e amministratore di rete. Per questo motivo è importante che tra i diversi ruoli si stabilisca una corretta comunicazione e un efficace coordinamento delle attività. Prerequisiti di installazione Prima di distribuire la soluzione Gruppi di disponibilità AlwaysOn, è importante verificare che il sistema soddisfi i requisiti, inclusi gli aggiornamenti. Per ulteriori informazioni sui prerequisiti della distribuzione di una soluzione Gruppi di disponibilità AlwaysOn, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server). Si consiglia di leggere con molta attenzione questo argomento prima di continuare. Su tutti i nodi deve essere installata la stessa versione del sistema operativo Windows Server e degli aggiornamenti software. Il sistema operativo server deve essere almeno Windows Server 2008 SP2 o Windows Server 2008 R2 SP1 con gli aggiornamenti minimi seguenti: Archiviazione asimmetrica (se si utilizza Windows Server 2008): http://support.microsoft.com/kb/976097 Voti dei nodi: http://support.microsoft.com/kb/2494036 Test di convalida dei dischi durante la convalida del cluster: http://support.microsoft.com/kb/2531907 Potrebbero essere necessari aggiornamenti aggiuntivi. 15 Configurazione della soluzione nel data center primario La Tabella 1 illustra il flusso di lavoro per la configurazione dei nodi del data center primario, presupponendo la presenza di due nodi. Passaggio 1. Aggiungere la funzionalità Clustering di failover ai due nodi situati nel data center primario. Per ulteriori informazioni sul processo, vedere Installare la funzionalità Clustering di failover. Per ulteriori informazioni sulla convalida dell'infrastruttura di rete e gli altri requisiti, vedere Informazioni sui requisiti per i cluster di failover. 2. Controllare i prerequisiti e installare gli aggiornamenti di Windows Server necessari in ogni nodo nel data center primario. 3. Assicurarsi che i volumi di archiviazione condivisa definiti per l'istanza del cluster di failover del data center primario siano formattati e provvisti di lettera di unità. È consigliabile che le lettere di unità e il percorso di directory dell'istanza del cluster di failover di DR corrispondano a quelli dell'istanza del cluster di failover primaria. Tenere presente questo aspetto durante l'assegnazione delle lettere di unità nell'istanza del cluster di failover primaria. 16 Amministratore Amministratore del database di Windows Server/ del cluster Sì, per il Sì coordinamento delle attività tra i ruoli Sì Sì Amministratore di rete Passaggio 4. Verificare che l'account che verrà utilizzato per installare e configurare il cluster WSFC sia un account di dominio. Questo account deve disporre anche delle autorizzazioni di amministratore per ogni nodo del cluster e delle autorizzazioni Create Computer Objects e Read All Properties per il contenitore utilizzato per gli account dei computer del dominio. In alternativa, è possibile preinstallare gli account degli oggetti nome anticipatamente o utilizzare un account amministratore di dominio per l'installazione. Per ulteriori informazioni sulle autorizzazioni necessarie e le opzioni di provisioning, vedere la sezione della guida dettagliata sui cluster di failover relativa alla configurazione degli account in Active Directory. 5. Utilizzando Gestione cluster di failover, eseguire la convalida del cluster dei due nodi server nel data center primario e dell'archiviazione condivisa che verrà aggiunta al cluster WSFC. Ripetere la convalida fino alla scomparsa di tutti gli errori che potrebbero impedire la prosecuzione del processo. Se viene consentito di passare al punto successivo con gli avvisi esistenti, è necessario comprendere tali avvisi per garantire una configurazione stabile. Per ulteriori informazioni sull'esecuzione di un test di convalida, vedere Convalidare la configurazione di un cluster di failover. 6. Al termine del passaggio di convalida del cluster, utilizzare Gestione cluster di failover per creare un cluster WSFC con due nodi. Per ulteriori informazioni, inclusa una panoramica dettagliata di questo processo, vedere Creare un nuovo cluster di failover. 17 Amministratore Amministratore del database di Windows Server/ del cluster Sì Amministratore di rete Sì Sì, per eventuali problemi relativi alla connessione in rete dei nodi Sì Sì, per eventuali problemi relativi alla connessione in rete dei nodi Passaggio 7. Assicurarsi che sia presente un numero dispari di voti, ad esempio aggiungendo una condivisione file o un altro nodo aggiuntivo, come descritto in precedenza in questo documento. Se si sceglie Maggioranza dei nodi e delle condivisioni file, prima di modificare la configurazione accertarsi di avere concesso le autorizzazioni di lettura e scrittura per la condivisione file di controllo all'account del cluster WSFC. 8. Assicurarsi che nell'installazione vengano utilizzate risorse di archiviazione condivise e formattate, accessibili solo ai due nodi situati nel data center primario. Questi dischi verranno utilizzati per SQL Server nel passaggio successivo. 9. Installare un'istanza del cluster di failover di SQL Server 2012 Enterprise nel data center primario. Per ulteriori informazioni, vedere Creare un nuovo cluster di failover di SQL Server (programma di installazione). È necessario eseguire due opzioni di installazione: la prima è Installazione nuovo cluster di failover di SQL Server, con la quale viene creata l'istanza del cluster di failover, mentre la seconda è Aggiungi nodo a cluster di failover di SQL Server sul secondo nodo nel data center primario. 18 Amministratore Amministratore del database di Windows Server/ del cluster Sì Sì Sì Amministratore di rete Passaggio 10. Dopo avere installato la prima istanza del cluster di failover, abilitare le funzionalità Gruppi di disponibilità AlwaysOn per entrambe le istanze di SQL Server. Per ulteriori informazioni sull'uso di Gestione configurazione SQL Server o, in alternativa, SQL Server PowerShell, vedere Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server). Notare che, quando si abilita Gruppi di disponibilità AlwaysOn per un'istanza, è necessario riavviare l'istanza per rendere effettiva la modifica. 19 Amministratore Amministratore del database di Windows Server/ del cluster Amministratore di rete Passaggio Amministratore Amministratore del database di Windows Server/ del cluster 11. Dopo avere abilitato l'istanza del cluster di failover di DR per il supporto di Gruppi di disponibilità AlwaysOn, eseguire il backup dei database utente di produzione dalla topologia legacy, quindi ripristinarli nell'istanza del cluster di failover del data center primario. Nota: è possibile scegliere di rinviare questo passaggio finché anche l'istanza del cluster di failover non sia disponibile e non sia possibile configurare il gruppo di disponibilità con due repliche. È inoltre necessario inserire in script gli altri oggetti SQL Server della topologia legacy da cui dipenderanno i database utente e che non sono contenuti nei database utente ripristinati (come gli account di accesso di SQL server, le autorizzazioni a livello di server associate e i processi di SQL Server Agent). Questo processo è simile a quello utilizzato per inserire in script oggetti dipendenti esterni al database sottoposto a mirroring in una relazione di mirroring. Sono disponibili diversi metodi per trasferire oggetti e principi di database tra istanze di SQL Server. Uno di questi è l'attività Trasferisci oggetti di SQL Server di Integration Services. Un altro metodo utilizzato per trasferire account di accesso e password tra istanze viene descritto qui: http://support.microsoft.com/kb/918992/ Tabella 1: compilazione della soluzione FCI+AG nel data center primario 20 Amministratore di rete Configurazione della soluzione nel data center di DR Questa tabella contiene il flusso di lavoro per la configurazione dei nodi del data center di ripristino di emergenza secondario e la creazione del gruppo di disponibilità. Passaggio Amministratore del database 1. Aggiungere la funzionalità Clustering di failover a tutti i nodi situati nel data center di ripristino di emergenza che fanno parte della soluzione. 2. Controllare i prerequisiti e installare gli aggiornamenti di Windows Server necessari in ogni nodo nel data center di DR. 3. Verificare che l'account che verrà utilizzato per installare e configurare il cluster WSFC sia un account di dominio. Questo account deve disporre anche delle autorizzazioni di amministratore per ogni nodo del cluster e delle autorizzazioni Create Computer Objects e Read All Properties per il contenitore utilizzato per gli account dei computer del dominio. Se si utilizzano gli stessi account del data center primario, queste autorizzazioni sono già impostate correttamente. 4. Utilizzando Gestione cluster di failover, eseguire la convalida del cluster dei due nodi server e dell'archiviazione condivisa aggiunti al cluster WSFC esistente. Se viene visualizzato il messaggio di avviso relativo all'archiviazione asimmetrica “Il disco con ID XYZ è visibile o impostabile come disco di tipo cluster solo da un sottoinsieme di nodi”, non è necessario intraprendere alcuna azione, in quanto si tratta di un messaggio previsto e accettabile per l'archiviazione asimmetrica. Ripetere la convalida fino alla scomparsa di tutti gli errori che potrebbero impedire la prosecuzione del processo. Sì, per il coordinamento delle attività tra i ruoli 21 Amministratore di Windows Server/ del cluster Sì Amministratore di rete Sì Sì Sì Sì, per eventuali problemi relativi alla connessione in rete dei nodi Passaggio Amministratore del database 5. Al termine della convalida, utilizzare Gestione cluster di failover per aggiungere i due nodi di ripristino di emergenza al cluster WSFC esistente. 6. Impostare la proprietà NodeWeight dei nodi WSFC del data center di ripristino di emergenza sul peso 0 (zero). Per un esempio, vedere la Figura 4: soluzione FCI+AG per HA/DR con assegnazione dei voti ai nodi. 7. Nell'installazione devono essere utilizzate risorse di archiviazione condivise e formattate, accessibili solo ai due nodi situati nel data center di DR. Questi dischi verranno utilizzati per SQL Server nel passaggio successivo. Mantenere le stesse lettere di unità e lo stesso mapping per semplificare la distribuzione del gruppo di disponibilità nei passaggi successivi e consentire le operazioni sui file di database che non richiedono intervento manuale o l'interruzione della sessione del gruppo di disponibilità. 8. Spostare le risorse di archiviazione disponibili in uno dei nodi del data center di DR per poterle utilizzare nel passaggio successivo. 9. Installare un'istanza del cluster di failover di SQL Server 2012 Enterprise nel data center di ripristino di emergenza. È necessario eseguire l'opzione Installazione nuovo cluster di failover di SQL Server su uno dei nodi per creare l'istanza del cluster di failover, quindi l'opzione Aggiungi nodo a cluster di failover di SQL Server sul secondo nodo nel data center di DR. 22 Amministratore di Windows Server/ del cluster Sì Amministratore di rete Sì, per eventuali problemi relativi alla connessione in rete dei nodi Sì Sì Sì Sì Sì, per coordinare l'approccio a porte e indirizzi IP (se si utilizzano indirizzi IP statici) Passaggio Amministratore del database 10. Il passaggio successivo all'installazione delle due istanze del cluster di failover consiste nell'abilitazione delle funzionalità Gruppi di disponibilità AlwaysOn nell'istanza di SQL Server del data center di DR. Sì Per informazioni dettagliate sull'uso di Gestione configurazione SQL Server o, in alternativa, di PowerShell, vedere Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server). Notare che, per rendere effettiva l'abilitazione di Gruppi di disponibilità AlwaysOn per l'istanza, sarà necessario riavviare l'istanza. 11. Inserire in script gli altri oggetti SQL Server della topologia legacy da cui dipenderanno i database utente e che non sono contenuti nei database utente ripristinati (come gli account di accesso di SQL server, le autorizzazioni a livello di server associate e i processi di SQL Server Agent). Si tratta degli stessi oggetti che sono probabilmente già stati inseriti in script e copiati nell'istanza del cluster di failover del data center primario. 12. Verificare la corretta impostazione dei possibili proprietari delle due istanze del cluster di failover: i possibili proprietari per INST_A devono essere PRIMARYNODE1 e PRIMARYNODE2, mentre i possibili proprietari per INST_B devono essere DRNODE1 e DRNODE2. 23 Sì Amministratore di Windows Server/ del cluster Amministratore di rete Passaggio Amministratore del database 13. Creare un gruppo di disponibilità Sì (questo passaggio coinvolge le istanze del cluster di failover primarie e di DR). È possibile impostare la modalità di disponibilità come asincrona o sincrona, a seconda delle caratteristiche dei carichi di lavoro e di rete dell'ambiente. Selezionare il failover manuale per il gruppo di disponibilità. In una soluzione FCI+AG il failover delle istanze del cluster di failover è automatico e il failover dei gruppi di disponibilità è manuale. Per ulteriori informazioni sulla configurazione del failover per questa soluzione, vedere Creazione e configurazione di gruppi di disponibilità (SQL Server). 14. Creare il listener del gruppo di Sì disponibilità. Questo passaggio non è necessario se il listener è già stato configurato come parte della creazione del gruppo di disponibilità. Per creare il listener del gruppo di disponibilità, è possibile utilizzare Transact-SQL, SQL Server PowerShell o una procedura guidata di SQL Server Management Studio. Per ulteriori informazioni sull'utilizzo dei diversi metodi, vedere Creare o configurare un listener del gruppo di disponibilità (SQL Server). Amministratore di Windows Server/ del cluster Amministratore di rete Sì, per assicurare che le porte degli endpoint siano aperte e in fase di risoluzione dei problemi, in base alle esigenze Sì Sì, per coordinare l'approccio a porte e indirizzi IP Tabella 2: compilazione della soluzione FCI+AG nel data center di ripristino di emergenza Dopo avere completato questi passaggi, si noterà che in Gestione cluster di failover di Windows, sotto Servizi e applicazioni, è stato creato un nuovo gruppo con lo stesso nome del gruppo di disponibilità. Il nuovo gruppo conterrà la risorsa listener del gruppo di disponibilità e gli indirizzi IP associati (vedere la Figura 5). 24 Figura 7: situazione della soluzione dopo la configurazione delle istanze del cluster di failover per HA e del gruppo di disponibilità per DR Nella Figura 7 viene illustrata la distribuzione della soluzione nel cluster WSFC. Notare che al listener del gruppo di disponibilità raffigurato è associato un solo indirizzo IP per scopi illustrativi, ma per le topologie con più data center è frequente la presenza di due indirizzi IP. Nota: anche se il gruppo di disponibilità viene visualizzato come risorsa nel cluster WSFC, non è opportuno tentare di gestirlo con Gestione cluster di failover o altre interfacce mirate alla gestione WSFC. Operare invece nel contesto dell'istanza di SQL Server tramite SQL Server Management Studio, Transact-SQL o Windows PowerShell. Per ulteriori informazioni sui motivi per cui evitare di utilizzare Gestione cluster di failover o altre interfacce mirate alla gestione WSFC, vedere il post di blog Evitare di utilizzare Gestione cluster di failover di Windows per eseguire il failover dei gruppi di disponibilità. Nella Figura 8 viene illustrata la distribuzione in SQL Server Management Studio. Una delle istanze del cluster di failover viene mostrata in Esplora oggetti con la gerarchia della cartella Disponibilità elevata AlwaysOn aperta. In questo esempio l'istanza del cluster di failover di DR è la replica secondaria, mentre l'altra istanza del cluster di failover è la replica primaria. Vengono elencati i tre database di disponibilità che fanno parte del gruppo insieme al nome del listener del gruppo di disponibilità. 25 Figura 8: situazione della soluzione dopo la configurazione delle istanze del cluster di failover per HA e del gruppo di disponibilità per DR in SQL Server Management Studio Considerazioni sul monitoraggio Quando si esegue la migrazione da una topologia con istanze del cluster di failover e mirroring del database a una soluzione basata su istanze del cluster di failover e un gruppo di disponibilità, è necessario adottare nuovi metodi per l'esecuzione del monitoraggio della topologia. I metodi e gli strumenti che è possibile utilizzare per il monitoraggio dell'infrastruttura del gruppo di disponibilità includono il dashboard AlwaysOn in SQL Server Management Studio, le informazioni sullo stato di Esplora oggetti, i criteri della Gestione basata su criteri, i contatori delle prestazioni correlati al nuovo gruppo di disponibilità, viste del catalogo, DMV e una sessione Eventi estesi che tiene traccia di esecuzioni recenti di istruzioni correlate al DDL AlwaysOn, problemi di connettività WSFC, eventi di failover, cambiamenti di stato e blocchi di thread di rollforward. Il dashboard AlwaysOn è lo strumento consigliato per visualizzare rapidamente l'integrità di un gruppo di disponibilità specifico. Nel dashboard vengono infatti inclusi il percorso dell'istanza primaria, la modalità di failover delle repliche, lo stato di sincronizzazione delle repliche e la conformità del failover delle varie repliche. I dati della sessione Eventi estesi di integrità AlwaysOn possono anche essere aperti direttamente dal dashboard per visualizzare l'attività recente del gruppo di disponibilità, i cambiamenti di stato e gli eventi. 26 Figura 9: dashboard AlwaysOn È inoltre possibile creare avvisi e risposte a processi di SQL Server Agent basati sulle soglie dei contatori delle prestazioni e sui cambiamenti di stato del gruppo di disponibilità. Per ulteriori informazioni e indicazioni sul monitoraggio dell'ambiente di un gruppo di disponibilità, vedere Monitoraggio di Gruppi di disponibilità (SQL Server). Ripristino in seguito a un'emergenza In questa sezione vengono descritti dettagliatamente i passaggi da seguire in caso di interruzione della replica primaria nel data center primario. Viene inoltre analizzata la procedura per ripristinare la disponibilità della replica primaria dal data center di ripristino di emergenza. L'interruzione della replica primaria può essere provocata da uno o più dei motivi seguenti: Errori di tutti i nodi delle istanze del cluster di failover nel data center primario Errori delle risorse di archiviazione delle istanze del cluster di failover nel data center primario Errori o interruzioni della rete che interessano l'intero data center primario In questi scenari si rendono necessarie determinate azioni nel data center di ripristino di emergenza per riprendere l'esecuzione del servizio SQL Server alle applicazioni. La Figura 10 mostra la finestra Informazioni sul quorum del cluster relativa a questo scenario. Le informazioni sono accessibili dal dashboard AlwaysOn, utilizzando il collegamento Visualizza informazioni sul quorum del cluster. Il quorum è quello di una situazione precedente al verificarsi di un'emergenza, in cui entrambi i nodi di DR possiedono zero voti. 27 Figura 10: stato dei voti del quorum del cluster prima di una situazione di emergenza Nel flusso di lavoro seguente vengono indicati i passaggi necessari per ripristinare un gruppo di disponibilità nel data center di ripristino di emergenza in caso di interruzione del data center primario. 1. Forzare il quorum su uno dei nodi di DR e assicurarsi che i nodi nel data center primario non formino il proprio quorum. È improbabile che Gestione cluster di failover avviato su un nodo di ripristino di emergenza fornisca inizialmente informazioni utili sullo stato del cluster WSFC, perché il cluster non possiede più il quorum. Figura 11: Gestione cluster di failover dopo che si è verificata un'emergenza e prima del ripristino Poiché dipendono da un cluster WSFC funzionante, le istanze del cluster di failover sono accessibili a meno che non siano attivi sia un quorum del cluster sia il servizio cluster. In uno scenario in cui lo stato del data center primario è incerto e il servizio deve essere ripristinato dal data center secondario di DR per rispettare l'obiettivo del tempo di recupero aziendale, è necessario forzare il quorum su uno dei nodi di DR. Il comando di Windows PowerShell seguente forza il quorum su uno dei nodi di DR. 28 Start-ClusterNode –Name “DRNODE1” –FixQuorum Dopo aver eseguito il comando, si otterrà un output simile al seguente. Name ------drnode1 State -------Joining Nota: se il servizio cluster è ancora in esecuzione su “DRNODE1”, è possibile utilizzare il comando seguente in Windows PowerShell per arrestare il servizio prima di avviare nuovamente il servizio cluster con il quorum forzato. Stop-ClusterNode –Name “DRNODE1” Per informazioni sugli altri strumenti che è possibile utilizzare per forzare il quorum, come cluster.exe o Gestione cluster di failover, vedere Forzare l'avvio di un cluster WSFC senza quorum. 2. Aprire Gestione cluster di failover per verificare lo stato del cluster Windows. A questo punto il cluster Windows deve essere attivo e in stato di quorum forzato e l'istanza del cluster di failover secondaria deve essere attiva. L'istanza del cluster di failover del data center primario sarà ancora offline, come le risorse del gruppo di disponibilità. Figura 12: Gestione cluster di failover dopo la forzatura del quorum 3. Portare online il gruppo di disponibilità nell'istanza del cluster di failover di ripristino di emergenza. Attenzione: se la replica è configurata con la modalità asincrona, il ripristino del servizio rischia di causare la perdita di dati per gli eventuali record di log non inviati. Assicurarsi di valutare correttamente le conseguenze di questa azione. Per ulteriori informazioni sulle azioni da intraprendere prima, durante e dopo questo tipo di failover manuale, vedere Eseguire un failover manuale forzato di un gruppo di disponibilità (SQL Server). Tramite SQL Server Management Studio connettersi all'istanza del cluster di failover nel data center di DR. I database di disponibilità dovrebbero indicare lo stato “Non in sincronizzazione”. L'istanza del cluster di failover apparirà in stato “Risoluzione”, come illustrato nella Figura 13. 29 Figura 13: Esplora oggetti in SQL Server Management Studio dopo la forzatura del quorum Notare nella Figura 13 che l'altra replica, che in questo esempio è ”SQLFCIPrimary\INST_A”, non mostra alcuno stato in Esplora oggetti all'interno della cartella “Repliche di disponibilità” di AG1. Si tratta dell'istanza del cluster di failover del data center primario che è non più accessibile a causa dell'interruzione. Se il rischio di perdita di alcuni dati è accettabile e il servizio deve essere ripristinato nel data center, eseguire la sintassi Transact-SQL riportata di seguito nell'istanza del cluster di failover di ripristino di emergenza per forzare il failover. ALTER AVAILABILITY GROUP [AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS; A questo punto, i database all'interno del gruppo di disponibilità dovrebbero essere disponibili. Vedere la Figura 14 per un esempio di stato di failover successivo alla forzatura. 30 Figura 14: Esplora oggetti dopo la forzatura del failover Con il ritorno online, nuove connessioni al listener del gruppo di disponibilità vengono automaticamente indirizzate alla replica primaria attuale, che è ora ospitata nell'istanza del cluster di failover di ripristino di emergenza. Notare inoltre che verranno ancora visualizzati vari messaggi di avviso relativi alla non disponibilità dei nodi del data center primario in SQL Server Management Studio. Nella Figura 15 viene mostrato un esempio della schermata. 31 Figura 15: dashboard AlwaysOn dopo un failover forzato 4. Da un nodo WSFC di DR rimuovere i voti dai nodi del data center primario e assegnare voti ai nodi del data center di DR. I voti possono essere rimossi anche se i nodi del data center primario non sono disponibili. I due nodi a cui è assegnato un peso di “1” sono i nodi WSFC di DR. (Get-ClusterNode “DRNode1”).NodeWeight=1 (Get-ClusterNode “DRNode2”).NodeWeight=1 (Get-ClusterNode “PrimaryNode1”).NodeWeight=0 (Get-ClusterNode “PrimaryNode2”).NodeWeight=0 Nota: se il sito di DR deve essere utilizzato per un periodo di tempo prolungato, si consiglia di aggiungere altri membri votanti (nodo WSFC o condivisione file). Prima di continuare, è possibile verificare che i voti dei nodi siano stati modificati nel modo desiderato tramite il comando di Windows PowerShell riportato di seguito. Get-ClusterNode | fl NodeName, NodeWeight Come già detto nel documento, la maggior parte degli ambienti delle grandi aziende prevede normalmente una separazione dei compiti tra i ruoli di amministratore del database, amministratore di Windows Server (o del cluster) e amministratore di rete. Nella tabella seguente viene riepilogato il flusso di lavoro del ripristino di emergenza descritto in precedenza, indicando le aree che tipicamente rientrano nella competenza dei vari ruoli aziendali dal punto di vista della pianificazione. 32 Passaggio Amministratore del database 1. Verificare l'attuale stato del data center primario e dei restanti nodi di ripristino di emergenza WSFC, coordinando gli interventi. 2. Forzare il quorum su uno dei nodi nel sito di DR per accedere all'istanza del cluster di failover di DR. 3. Forzare il failover del gruppo di disponibilità all'istanza del cluster di failover di ripristino di emergenza. 4. Aggiungere i voti ai nodi di DR e rimuovere i voti dai nodi primari. Sì Amministratore di Windows Server/del cluster Sì Amministratore di rete Sì Sì Sì Sì Tabella 3: ripristino in seguito a un'emergenza in base al ruolo Ripristino del data center primario Nello scenario illustrato in questo documento si presuppone che il ripristino del servizio nel data center di ripristino di emergenza costituisca uno stato temporaneo in attesa della risoluzione dei problemi del data center primario. Uno scenario di interruzione può presentare diverse variazioni, che si ripetono quindi anche nella fase di ripristino. Nello scenario descritto qui si presuppone una situazione di emergenza in cui i server del data center primario sono inattivi per un periodo di tempo prolungato. Una volta risolti i problemi e riattivati i nodi nel data center primario, tali nodi tentano di connettersi al cluster WSFC. Dopo la riconnessione al cluster WSFC con i servizi cluster in esecuzione, i pesi assegnati al nodo di ripristino di emergenza dovrebbero tornare effettivi. Inoltre, nello scenario si presuppone che le installazioni originali di SQL Server e i database associati siano ancora intatti. Lo stato della replica nell'istanza del cluster di failover nel data center primario in cui si è precedentemente verificato l'errore sarà “Non in sincronizzazione” (vedere la Figura 16). 33 Figura 16: SQL Server Management Studio dopo il ripristino dell'istanza del cluster di failover primaria ma prima della ripresa del gruppo di disponibilità L'istanza di SQL Server del sito di DR (in questo esempio “SQLFCIDR\DC2”) è ancora la replica primaria. Notare inoltre il simbolo di “Pausa” accanto a ogni database di disponibilità sotto la cartella Database di disponibilità. A questo punto è necessario valutare se sia necessario recuperare eventuali dati (ovvero le modifiche apportate ai dati nella replica primaria originale non inviate alla replica DR appena prima del verificarsi dell'emergenza) o procedere con la riattivazione delle sessioni di replica. Attenzione: la ripresa delle repliche del gruppo di disponibilità in questa fase potrebbe provocare la perdita di dati. Se tale perdita non è accettabile, è necessario recuperare i dati prima di riprenderne lo spostamento. Per contro, se non si riprende l'attività del gruppo di disponibilità, i file di log delle transazioni continuano ad aumentare di dimensione nei database di replica di DR. Un metodo per recuperare i dati consiste nel creare uno snapshot del database nei database secondari sospesi (ovvero i database primari originali) allo scopo di estrarre i dati appropriati necessari per la risincronizzazione con la versione della replica di DR dei database di disponibilità. Nell'esempio seguente viene mostrato come creare uno snapshot del database in un database di disponibilità con stato “Non in sincronizzazione”. -- Create the database snapshot CREATE DATABASE AppDB_A1 ON ( NAME = AppDB, FILENAME = 'R:\MSSQL11.MSSQLSERVER\MSSQL\Data\AppDB_A1.ss' ) AS SNAPSHOT OF AppDB; GO 34 È ora possibile estrarre i dati richiesti dallo snapshot del database e inserirli in modo appropriato nella replica primaria attuale, prima di procedere con la ripresa dello spostamento dei dati. Nota: per ulteriori informazioni sui rischi della forzatura del failover e sulla riduzione della perdita di dati, vedere Failover e modalità di failover (gruppi di disponibilità AlwaysOn). Una volta valutata e risolta in modo soddisfacente la questione della perdita di dati e giunto il momento di ripristinare il servizio nel data center primario, il passaggio successivo consiste nel riportare in modo controllato il ruolo di replica primaria al data center primario: 1. Avviare la migrazione controllata di ritorno al data center primario aggiungendo nuovamente i voti del quorum ai due nodi del data center primario. Dopo avere configurato questa impostazione, verificare di nuovo che tutti i nodi nel cluster WSFC possiedano un voto. 2. Per riprendere le sessioni di ogni database che fa parte del gruppo di disponibilità, eseguire una serie di comandi ALTER DATABASE di Transact-SQL sull'istanza del cluster di failover del data center primario. Esempio: ALTER DATABASE AppDB SET HADR RESUME; GO ALTER DATABASE ConfigDB SET HADR RESUME; GO ALTER DATABASE ReportDB SET HADR RESUME; GO 3. Per effettuare la sincronizzazione prima del failover, modificare il gruppo di disponibilità nell'istanza del cluster di failover di DR in modo da utilizzare temporaneamente la modalità di disponibilità con commit sincrono. Idealmente, il commit sincrono deve essere impostato durante un periodo di bassa attività dell'applicazione per ridurre l'impatto sugli utenti della latenza delle transazioni. Di seguito è riportato un esempio del comando Transact-SQL (eseguito sull'istanza del cluster di failover primaria attuale nel data center di ripristino di emergenza), dove AG1 è il gruppo di disponibilità e la replica nel data center primario è definita come SQLFCIPrimary\INST_A. USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO Nella stessa sessione di SQL Server Management Studio eseguire il comando riportato di seguito per impostare il commit sincrono anche sulla replica di DR. USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH 35 (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO 4. Verificare lo stato della sincronizzazione tra le due posizioni. Per proseguire con il passaggio successivo è necessario che lo stato delle due repliche sia “Integro”, a indicare che le repliche, entrambe con commit sincrono, sono sincronizzate. SELECT role_desc, synchronization_health_desc FROM sys.dm_hadr_availability_replica_states; 5. Per eseguire il failover dall'istanza del cluster di failover del data center di ripristino di emergenza all'istanza del cluster di failover del data center primario precedente, connettere ed eseguire lo script riportato di seguito sull'istanza del cluster di failover del data center primario che diventerà la nuova replica primaria. ALTER AVAILABILITY GROUP [AG1] FAILOVER; 6. Se la topologia in uso è impostata sulla modalità a prestazioni elevate, come detto in precedenza, impostare di nuovo il nodo della replica dell'istanza del cluster di failover di ripristino di emergenza sul commit asincrono. Eseguire il comando Transact-SQL riportato di seguito sulla replica primaria. USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIDR\INST_B' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO USE [master] GO ALTER AVAILABILITY GROUP [AG1] MODIFY REPLICA ON N'SQLFCIPrimary\INST_A' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO 7. Rimuovere i voti del quorum dai nodi di ripristino di emergenza. 36 Nella tabella seguente viene riepilogato il flusso di lavoro del ripristino di emergenza descritto in precedenza, indicando le aree che tipicamente rientrano nella competenza dei vari ruoli aziendali dal punto di vista della pianificazione. Passaggio 1. Dopo il ripristino del servizio, dei nodi e delle istanze del cluster di failover del data center primario, aggiungere di nuovo i voti del quorum ai nodi primari originali. 2. Riprendere le sessioni dei database di disponibilità su ogni replica secondaria. 3. Impostare la replica dell'istanza del cluster di failover di ripristino di emergenza e la replica dell'istanza del cluster di failover del data center primario sul commit sincrono. 4. Verificare lo stato della sincronizzazione tra le due posizioni. Per proseguire con il passaggio successivo è necessario che lo stato di entrambe le repliche sia “Integro”. 5. Eseguire il failover a una replica dell'istanza del cluster di failover nel data center primario. 6. Ripristinare il commit asincrono nella replica di ripristino di emergenza (per la corrispondenza con la configurazione originale). 7. Rimuovere i voti dai nodi WSFC di DR. Tabella 4: ripristino del data center primario 37 Amministratore del database Amministratore di Windows Server/del cluster Sì Sì Sì Sì Sì Sì Sì Amministratore di rete Conclusione È possibile utilizzare i gruppi di disponibilità AlwaysOn di SQL Server 2012 per sostituire il mirroring del database nelle topologie che utilizzano le istanze del cluster di failover per la disponibilità elevata e il mirroring del database per il ripristino di emergenza. Questo modello di progettazione offre funzionalità più ampie rispetto a quelle delle versioni precedenti, consentendo l'uso di unità di failover con più database, repliche di sola lettura e altro ancora. Lo scopo di questo white paper è stato presentare una nuova soluzione per HA e DR basata su istanze del cluster di failover AlwaysOn e gruppi di disponibilità AlwaysOn per sostituire l'architettura legacy. Il successo della distribuzione di una soluzione HA/DR di questo tipo dipende non solo dal team di amministrazione del database, ma anche dalla stretta collaborazione tra tale team, il team di amministrazione di Windows Server e il team dei servizi di rete dell'organizzazione IT. Lo scambio di informazioni e il supporto incrociato delle competenze sono di estrema importanza nella distribuzione della soluzione HA/DR. Riferimenti 38 Modelli di progettazione per la disponibilità elevata e il ripristino di emergenza di SQL Server 2012 AlwaysOn (http://go.microsoft.com/fwlink/?LinkId=255048) Guida alle soluzioni Microsoft SQL Server AlwaysOn per la disponibilità elevata e il ripristino di emergenza (http://msdn.microsoft.com/library/hh781257.aspx) Istanze del cluster di failover AlwaysOn (SQL Server) (http://technet.microsoft.com/library/ms189134.aspx) Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server) (http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx) Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server) (http://technet.microsoft.com/library/ff929171.aspx) Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server)(http://technet.microsoft.com/library/ff878487(v=sql.110).aspx) Guida dettagliata sui cluster di failover: configurazione del quorum in un cluster di failover (http://technet.microsoft.com/library/cc770620(v=WS.10).aspx) Hotfix di Windows Server per i voti del quorum (http://support.microsoft.com/kb/2494036) Windows PowerShell (http://technet.microsoft.com/library/bb978526) Mapping dei comandi di Cluster.exe ai cmdlet di Windows PowerShell per i cluster di failover (http://technet.microsoft.com/library/ee619744(v=WS.10).aspx) Manuale di riferimento di base per Windows PowerShell (http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survivalguide-it-it.aspx) Cmdlet specifici per i cluster di failover in Windows PowerShell (http://technet.microsoft.com/library/ee461009.aspx) SQL Server PowerShell (http://msdn.microsoft.com/it-it/library/hh245198.aspx) Per ulteriori informazioni Sito Web SQL Server (http://www.microsoft.com/italy/server/sql/) TechCenter di SQL Server (http://technet.microsoft.com/it-it/sqlserver/) Risorse online per gli sviluppatori di SQL Server (http://msdn.microsoft.com/it-it/sqlserver/) Il documento è risultato utile? Esprimere una valutazione utilizzando una scala compresa tra 1 (scarso) e 5 (eccellente), indicandone i motivi. Ad esempio: La valutazione è alta perché il documento contiene esempi validi, catture di schermate nitide, spiegazioni chiare o altri motivi? La valutazione è bassa perché il documento contiene esempi confusi, catture di schermate sfocate, spiegazioni poco chiare? I commenti aiuteranno Microsoft a migliorare la qualità dei white paper pubblicati. Commenti e suggerimenti 39
