SQL Server

Suggerimenti per il clustering di SQL Server

Tom Moreau, PhD

Panoramica:

• Esecuzione di SQL Server su cluster
• Requisiti hardware e software
• Clustering di un nodo
• Opzioni efficaci dal punto di vista dei costi

Un cluster di server consente di connettere un numero di server fisici, o nodi, che fungono da partner di failover. La ridondanza di un cluster fornisce tempi di operatività più lunghi per

le operazioni critiche. Ho implementato molti cluster in 13 anni di lavoro utilizzando SQL Server™, ciascuno con una serie specifica di problemi. Quest'esperienza mi ha consentito di raccogliere una serie di consigli per agevolare e semplificare il clustering.

I cluster di server si avvalgono delle funzionalità di clustering integrate nella versione Enterprise Edition della famiglia Windows Server®. Per quanto riguarda il clustering, Windows Server 2003 è considerevolmente migliore di Windows 2000 Advanced Server. Per ottimizzare i vantaggi del clustering, occorre l'hardware giusto, il che implica un investimento. Non è sufficiente collegare due server mediante un disco condiviso, né affidarsi al fatto che i singoli componenti hardware appartengano al catalogo Windows® (in passato conosciuto come Elenco di compatibilità hardware). Il sistema nel suo insieme deve appartenere al Catalogo di Windows. Sono disponibili soluzioni cluster approvate e a basso costo. Nella Figura 1 è mostrata una tipica configurazione cluster.

Figura 1** Un cluster tipico **(Fare clic sull'immagine per ingrandirla)

Il clustering non è fatto di solo hardware; occorre anche scegliere l'edizione giusta di SQL Server 2005. Enterprise Edition abilita il clustering e altre funzionalità utili, come la capacità di sfruttare più CPU, viste distribuite e partizionate aggiornabili, distribuzione dei log incorporata, uso automatico di viste indicizzate. Se già si dispone di una licenza Enterprise Edition, si consiglia di prendere in considerazione il clustering, anche se non si dispone del numero di server necessario a formare un cluster tradizionale, da due a otto nodi (parleremo dei cluster a un nodo più avanti). Se si dispone di SQL Server 2005 Standard Edition, è possibile installare un cluster a due nodi.

Windows Server 2003 Enterprise Edition e Datacenter Edition hanno il clustering integrato, ed è sufficiente eseguire Amministrazione cluster per configurare il cluster. È possibile aggiungere tutti i nodi con un'operazione unica o inserirli uno per volta. Allo stesso modo, quando si installa SQL Server, è possibile eseguire l'installazione su un server singolo non in cluster o installare un'istanza virtuale su un cluster. Se si decide di installare un'istanza virtuale, è possibile farlo su tutti i nodi del cluster, su alcuni nodi o su un nodo soltanto.

Infine, per ottenere l'elevata disponibilità clustering, occorrono persone qualificate e procedure collaudate da seguire in caso di problemi. Sebbene il clustering fornisca un'ottima protezione dagli errori hardware, non può impedire gli errori degli utenti, ad esempio nel caso in cui un amministratore di database assonnato perda una tabella di importanza critica nel mezzo della notte.

Cluster a un nodo

Anche se è necessario un solo server, è consigliabile creare un cluster a un nodo. Sarà sempre possibile potenziarlo in un secondo momento, evitando di ricrearlo dal nulla. Accertarsi che l'hardware scelto si trovi nella sezione cluster del Catalogo di Windows.

L'aggiunta di un nodo in un secondo momento non è mirata unicamente a ottenere l'alta disponibilità. Potrebbe ad esempio succedere che il server in uso non disponga della capacità necessaria. Per ovviare al problema, occorrerebbe intervenire con una migrazione, ossia un dispendio di tempo ed energie. In un cluster a un nodo invece, la migrazione è facilitata e i tempi di inattività inferiori. Basta aggiungere il nuovo nodo al cluster, i valori binari e service pack SQL Server al nuovo nodo ed eseguire il failover sul nuovo nodo. Quindi, aggiungere gli aggiornamenti successivi ai service pack e rimuovere il vecchio nodo. Il tempo di inattività richiesto è quello necessario a eseguire il failover e aggiungere gli aggiornamenti, se presenti.

Aggiunta di nodi

Poiché tutti i nodi di un cluster devono essere uguali, è meglio agire per tempo per aggiungere un nodo. Se si attende troppo a lungo si rischia che il nodo vada fuori produzione. In uno dei progetti a cui ho lavorato, dovevo occuparmi della ricostruzione di un nodo in un cluster SQL Server 2000. L'amministratore di rete/SO si era occupato della costruzione del computer di base, poi ero intervenuto io per aggiungerlo al cluster e prepararlo a funzionare come nodo SQL Server. Non ci sono stati problemi fino al momento del failover sul nuovo nodo. L'operazione generava errore. Nonostante avessi preparato un documento dettagliato sulla costruzione del nuovo cluster, compresa l'aggiunta degli account dei servizi cluster e SQL Server per entrambi i nodi, il documento non era stato seguito. L'amministratore non aveva aggiunto gli account dei servizi al nodo ricostruito, pertanto i privilegi che vigevano prima della ricostruzione erano andati persi.

Non riuscivo a risolvere il problema, finché non pensai di controllare l'appartenenza al gruppo locale. Una volta aggiunti i due account, il failover è riuscito. L'episodio mi aveva fatto pensare. Ricostruire un nodo è un'operazione che non viene eseguita di frequente, spesso eseguita in situazioni di emergenza. Avevo preparato un documento, ma non era stato utilizzato. Avremmo potuto automatizzare la parte di protezione scrivendo un breve script da aggiungere ai due account ed eseguire le personalizzazioni necessarie. In SQL Server 2005 le cose sono state migliorate. Il programma di installazione richiede di impostare gruppi a livello di dominio per gli account del servizio SQL Server.

Ciò mi ha fatto pensare ulteriormente. È possibile creare degli script che invocano CLUSTER.EXE per aggiungere il nodo al cluster Microsoft® Cluster Server (MSCS). Basta inserire nello script il nome del nodo. In una situazione di emergenza, l'automazione è fondamentale.

Cluster N+1

Non sempre per aggiungere un nodo a un cluster occorre sostituirne un altro. È possibile aggiungere più istanze SQL Server al cluster e ogni istanza richiede risorse disco separate. Tuttavia, più istanze eseguite su un solo nodo condividono CPU e RAM, con il rischio di causare un calo delle prestazioni. In una situazione ideale, si dovrebbe eseguire un'istanza per nodo. Come è possibile garantire che ciò accada durante il failover? Semplice: un nodo rimane libero mentre sui nodi restanti sono eseguite singole istanze SQL Server. È questa la definizione di cluster N+1: N istanze eseguite su N+1 nodi. Il nodo extra è il backup.

Aggiornamento di SQL Server

L'aggiornamento di un'istanza cluster di SQL Server non è un'operazione semplice. Il cluster ha uno scopo preciso: migliorare i tempi di attività. SQL Server 2005, da parte sua, offre numerosi miglioramenti per evitare i tempi di inattività.

Quali sono le opzioni disponibili? La soluzione più costosa: creare un cluster completamente nuovo, con nuovi server ed eventualmente una nuova rete di archiviazione SAN. Gli unici componenti immutati rimangono gli switch di rete. Ovviamente, l'approccio non è economico ma ha diversi vantaggi. Il nuovo hardware dà prestazioni migliori del vecchio, oltre a presentare l'aumento della capacità del disco e della velocità. Il cambiamento di hardware potenzia quindi le prestazioni. Una soluzione potrebbe essere quella di adottare una formula leasing.

Una volta configurato il nuovo hardware, è possibile creare il nuovo SQL Server virtuale, copiarvi i database di produzione, quindi mettere in funzione il nuovo sistema, dopo avere testato eventuali bug prima dell'attivazione. Ricordarsi di trasferire gli accessi del server esistente Vedere anche support.microsoft.com/kb/246133. Un'altra ottima idea consiste nell'aggiornare lo script di creazione dell'accesso in caso di errore irreversibile.

Per minimizzare il tempo di inattività, utilizzare la distribuzione dei log, a meno che i database non siano di dimensioni limitate e ci siano periodi di tempo lunghi in cui gli utenti non si connettano. È possibile eseguire la distribuzione dei log fino a un attimo prima dell'attivazione. Dopodiché, una volta disconnessi gli utenti, tagliare e distribuire il log finale, quindi utilizzare l'applicazione su una nuova istanza Per un'alternativa interessante alla distribuzione del log, vedere la sezione di mirroring del database che segue. Se si fa uso di alias DNS, non sarà necessario farlo. Sarà sufficiente aggiornare gli alias DNS. Quest'approccio ha il vantaggio di conservare l'originale, nel caso in cui a metà dell'operazione di migrazione sia necessario tornare indietro.

Esiste un'alternativa meno costosa, che richiede però un'attenta pianificazione. Un cluster è in grado di supportare più istanze SQL Server, ma ogni istanza deve disporre di risorse disco proprie. Durante la divisione della SAN, assegnare una LUN a un aggiornamento futuro. Per eseguire l'aggiornamento, installare i valori binari SQL Server nella risorsa disco. Preparare il sistema e chiudere l'istanza corrente di SQL Server, spostare le risorse disco dal vecchio gruppo SQL Server, aggiornare le dipendenze e mettere in linea la nuova istanza SQL Server. Collegare il database della vecchia istanza per completare l'operazione. Prima di iniziare, eseguire il backup.

Si tratta dell'opzione più economica che comporta però alcuni rischi. Se qualcosa non funziona, non sarà possibile scollegare i database dalla nuova istanza e rimetterli nella posizione originale. Sarà necessario ricorrere al ripristino dal backup e ciò potrebbe implicare lunghi tempi di inattività.

Un'alternativa consiste nell'inserire due istanze di SQL Server nella SAN, purché lo spazio sia sufficiente. Eseguire il ripristino dei backup (e distribuzione dei log) nella nuova istanza, come indicato sopra, ma in questo caso sarà disponibile un fallback. Una volta completata la migrazione, è possibile liberare le risorse SAN dalla vecchia istanza. L'unico costo è quello dei dischi aggiuntivi.

Bilanciamento del carico

Innanzitutto sfatiamo una credenza errata. Lo scopo del clustering MSCS è fornire disponibilità elevata e non bilanciamento del carico. SQL Server non dispone di alcuna funzione di bilanciamento del carico automatica integrata. Di questo è responsabile la progettazione fisica delle applicazioni. Cosa significa?

La crescita della tabella implica la riduzione delle prestazioni, soprattutto quando si eseguono ricerche nelle tabelle. Quando entrano in gioco miliardi di righe di dati, la soluzione tradizionale è utilizzare viste partizionate, fatte di tabelle con schemi identici collegati da UNION ALL. Per differenziare le tabelle dei membri, inoltre, sono impiegati i vincoli CHECK; ciò evita la duplicazione di dati nella vista partizionata. Se la colonna utilizzata nel vincolo CHECK è anche parte della chiave primaria, la vista è aggiornabile.

Se le tabelle dei membri sono a loro volta filegroup, è possibile ottenere prestazioni migliori del disco se i filegroup si trovano su unità fisiche separate. Le tabelle possono trovarsi anche in database separati. In SQL Server 2005, tuttavia, purché tutti i dati si trovino nello stesso database, è possibile utilizzare la partizione della tabella, molto più semplice da implementare.

Se tuttavia, nonostante la partizione della tabella o le viste partizionate (locali) le prestazioni rimangono lente, in SQL Server 2000 o SQL Server 2005 è possibile utilizzare le viste partizionate distribuite. La differenza principale è che le tabelle dei membri possono risiedere su istanze diverse di SQL Server e queste istanze possono essere installate su un cluster N+1. Vantaggi dell'opzione Se una tabella di membri non è più in linea in una vista partizionata, l'intera vista risulta non in linea. Raccogliere questi membri in un cluster offre l'affidabilità necessaria per supportare le prestazioni e fornire il bilanciamento del carico.

Effettiva necessità del cluster

Per chi dispone di alcuni server di riserva che non sono nel catalogo Windows per i cluster e non desidera investire in nuovi server per supportare un cluster,

un'alternativa attraente al clustering potrebbe essere il mirroring del database. Il mirroring coinvolge tre elementi: un'istanza che ospita il database con mirroring, detto database principale; un server di backup detto server mirror e, se si desidera il failover automatico, un terzo server noto come server di controllo. In pratica, una transazione che avviene nel database principale viene eseguita anche in quello mirror. Se il database principale genera un errore, esegue automaticamente il failover sul database mirror, purché esista un server di controllo. Occorre configurare il mirroring per tutti i database applicativi e non è possibile eseguire il mirroring dei database di sistema.

A differenza del cluster, il mirror è un istanza separata di SQL Server ed è disponibile in modalità remota. Le cache sono popolate dall'attività di aggiornamento che avviene come risultato delle transazioni duplicate dal database principale. Si presuppone che l'unica attività che avviene nel database mirror sia la ricezione delle transazioni con mirroring effettuate in quello principale. Il failover è generalmente più veloce rispetto a un cluster poiché SQL Server è già in esecuzione sul server mirror. Poiché le cache sono parzialmente riempite, le prestazioni iniziali non sono lente come avviene nel cluster. Quando il database con mirroring esegue il failover, i ruoli di database principale e mirror si invertono.

Il lato negativo del mirroring del database sta nel fatto che necessita del doppio della capacità totale del disco rispetto al cluster. La struttura richiede inoltre più alimentazione della CPU se si utilizza la modalità sincrona senza perdita di dati. Come già detto, ottenere disponibilità elevata non è un operazione economica.

Approccio combinato

Il fatto che il server mirror possa risiedere lontano dal server principale ne fa un'ottima scelta per pianificazioni di ripristino di emergenza. Il cluster è una prima linea di difesa; ma cosa succede se si impiegano sia cluster sia mirroring? Durante il failover del cluster, se la configurazione mirror include un server di controllo, il database mirror diventa database principale quando SQL Server sta per mettersi in linea. Tuttavia, il failover dal database principale a quello mirror (in cluster) non è automatico. È meglio perciò non attivare il failover automatico per i database con mirroring se utilizzati in congiunzione con un cluster.

Il vantaggio del mirroring non si limita a DR, ma risulta utile anche per applicare un service pack o un aggiornamento rapido al database principale; in questa situazione è possibile eseguire il failover manuale sul mirror. Durante l'applicazione del service pack o dell'aggiornamento rapido, il server che era quello principale è temporaneamente non in linea e le transazioni sottoposte a commit nel nuovo server principale vengono messe in coda, in attesa di essere rispedite al nuovo server mirror (ex principale). Una volta completata l'installazione di service pack o l'aggiornamento rapido, ha luogo la sincronizzazione e alla fine i due server si troveranno completamente in sincronia. A questo punto, è possibile invertire i ruoli di server principale e mirror. Il tempo di inattività si limita ai pochi secondi necessari a eseguire failover e failback. È possibile utilizzare questo approccio per eseguire la migrazione di SQL Server a un altro computer: basta non impostare il failback.

Server virtuale per una flessibilità maggiore

La virtualizzazione consente di eseguire uno o più sistemi operativi simultaneamente su un unico server fisico. Il software di virtualizzazione aggiunge un altro strato di funzionalità al concetto di cluster perché abilita il cluster del software. Conseguentemente, se il server host genera errore, è possibile eseguire il failover di server e dei sistemi operativi guest su un nodo di backup. Si tratta di un metodo molto facile per eseguire la migrazione su un server guest. Inoltre, il SO guest non deve essere dotato di funzionalità cluster. In questo modo, è possibile eseguire SQL Server Workgroup Edition in Windows Server 2003 guest, con Microsoft Virtual Server 2005 in esecuzione su cluster. Indirettamente, si tratta di eseguire un cluster in Workgroup Edition (vedere la figura 2).

Figura 2** Uso di un server virtuale **(Fare clic sull'immagine per ingrandirla)

Controllo

Il responsabile di un'implementazione SQL Server deve poter contare su un server sempre disponibile. Il clustering di server serve ad assicurare che ciò avvenga. In quest'articolo sono forniti alcuni importanti suggerimenti di base; informazioni più dettagliate sono disponibili nell'intestazione laterale "Risorse di clustering".

Risorse di clustering

Per ulteriori informazioni sui metodi qui citati e i vari prodotti necessari alla configurazione del cluster Server di SQL, vedere:

• Clustering di failover di SQL Server 2005
• Clustering di failover di SQL Server 2000
• Windows Server 2003 R2 Enterprise Edition – Cluster Server (in inglese)
• Guida dell'amministratore di server cluster Microsoft
• Microsoft Virtual Server 2005 R2 (in inglese)

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, è un consulente indipendente specializzato in amministrazione, progettazione e implementazione di database SQL Server, con sede a Toronto. Tom utilizza SQL Server dal 1993 ed è MVP dal 2001. Ha scritto oltre 100 articoli ed è coautore di un libro su SQL Server. Un ringraziamento a Geoff Hiten, MVP per SQL Server per il suo prezioso contributo.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.