Amministrazione di Windows

Introduzione a Clustering di failover di Windows Server 2008

Chuck Timon

 

Panoramica:

• Snap-in Gestione cluster di failover
• Nuove funzionalità e miglioramenti
• Funzionalità di backup e ripristino
• Migrazione da Windows Server 2003

Indice

Nuova interfaccia di gestione
Miglioramento del processo di configurazione
Procedura di convalida incorporata
Nuovo modello quorum
Miglioramenti delle funzionalità di sicurezza
Estensione della funzionalità di connessione in rete
Maggiore affidabilità nell'interazione con l'archivio
Processi di ripristino incorporati
Nuova funzionalità di backup e ripristino
Migrazione dai cluster di server di Windows Server 2003

Fin da quando il clustering è stato introdotto la prima volta in Windows NT 4.0 Enterprise Edition, gli utenti si sono lamentati perché lo ritengono troppo difficile da configurare e persino più difficile da gestire. L'amministrazione di un cluster ha richiesto

all'amministratore di avere qualcosa di più della semplice conoscenza dell'elemento di clustering in sé: gli ha di fatto imposto di avere una conoscenza approfondita sia delle tecnologie di archiviazione sia del modo in cui il servizio cluster avrebbe interagito con le diverse soluzioni di archiviazione. All'interno di molte organizzazioni, il bagaglio completo di competenze necessario per rendere operativa una soluzione ad alta disponibilità, e in seguito gestirla, era davvero complicato da reperire.

Con il passare degli anni il clustering è stato migliorato, ma lasciava ancora molto a desiderare quando Microsoft iniziò a lavorare su Windows Server® 2008. Avendo ben presente il problema, il team iniziò a riprogettare il clustering cercando di raggiungere l'obiettivo principale della semplicità. In Windows Server 2008, Microsoft® Cluster Services (MSCS) è stato sottoposto a una ristrutturazione completa, con conseguente cambiamento del nome che ora è Clustering di failover.

Questo non significa che la semplicità sia l'unico contributo che l'implementazione di Clustering di failover ha da offrire. Con gli anni, Microsoft ha imparato molte lezioni, poiché le organizzazioni hanno fornito commenti e suggerimenti preziosi riguardo a quello che avrebbero voluto vedere in una soluzione di clustering. La nuova funzionalità Clustering di failover risolve molte delle questioni cruciali segnalate dagli utenti, oltre a introdurre alcune nuove funzionalità interessanti capaci di renderla una proposta davvero attraente. In questo articolo, vorrei presentare alcune delle nuove funzionalità che Clustering di failover di Windows Server 2008 mette a disposizione degli utenti.

Nuova interfaccia di gestione

Dopo aver installato Clustering di failover, è possibile accedere all'interfaccia Gestione cluster di failover tramite Strumenti di amministrazione oppure eseguendo Cluadmin.msc. Al pari di altre interfacce di gestione in Windows Server 2008, lo snap-in Gestione cluster di failover è un'utilità di Microsoft Management Console (MMC) 3.0. Per i veterani dei cluster, aprire per la prima volta lo snap-in Gestione cluster di failover sarà un po' come ritrovarsi in un paese straniero senza neanche avere una cartina stradale.

La nuova interfaccia è divisa in tre riquadri separati, come illustrato nella Figura 1. Nel riquadro di sinistra sono riportati tutti i cluster di failover di Windows Server 2008 presenti nell'organizzazione. Il riquadro centrale fornisce i dettagli relativi alla parte di configurazione del cluster selezionata nel riquadro di sinistra, mentre il riquadro di destra mostra le azioni che possono essere eseguite.

Figura 1 Snap-in Gestione cluster di failover (fare clic sull'immagine per ingrandirla)

Immaginiamo, ad esempio, di selezionare Archiviazione nel riquadro di sinistra. Il riquadro centrale riporterà i dettagli sul provisioning dell'archivio nel cluster, oltre a indicare quale archivio è eventualmente disponibile al momento. Come si può vedere nella Figura 1, il cluster contiene una parte di archivio che supporta un disco witness, un archivio che è stato predisposto per un file server e le risorse di archivio disponibili. Il riquadro di destra visualizza le azioni possibili, come ad esempio l'aggiunta di risorse per l'archiviazione. Tenere presente che lo snap-in Gestione cluster di failover non può essere utilizzato per amministrare versioni precedenti di Microsoft Clustering Services.

Miglioramento del processo di configurazione

Configurare un cluster di failover è davvero facile. Molte delle azioni necessarie per la configurazione, la riconfigurazione e la gestione dispongono di procedure guidate, grazie alle quali gli amministratori non devono più preoccuparsi di sapere se le risorse sono configurate correttamente o se si connettono nell'ordine giusto.

La Figura 2 mostra la Configurazione guidata disponibilità elevata. In questo esempio specifico, è stato configurato un file server. Sulla sinistra si vede l'elenco dei passaggi che la procedura guidata ha proposto all'amministratore. Una volta terminato il processo, viene visualizzata una pagina di riepilogo ed è possibile vedere un report.

Figura 2 Configurazione guidata disponibilità elevata (fare clic sull'immagine per ingrandirla)

Procedura di convalida incorporata

Nelle versioni precedenti di Windows Server, per essere considerate soluzioni cluster supportate, le configurazioni hardware dovevano essere elencate come soluzione cluster nel Catalogo di Windows Server . Questo riguardava anche i cluster multisito, che erano riportati separatamente nella categoria dei cluster geograficamente lontani. Per essere inseriti nel catalogo, i fornitori hardware dovevano eseguire una set di test WHQL (Windows Hardware Quality Lab) e inviare i risultati a Microsoft. Si trattava di una proposta onerosa per il fornitore e inoltre il database del Catalogo di Windows Server era difficile da gestire.

In Windows Server 2008, Clustering di failover include un processo di convalida che è incorporato. Il processo è composto da una serie di test raggruppati in quattro categorie principali, come illustrato nella Figura 3.

Figura 3 Categorie dei test di convalida di Clustering di failover (fare clic sull'immagine per ingrandirla)

Come si può vedere, la categoria Rete è espansa per mostrare i test che vengono eseguiti; ogni categoria contiene una a serie di test. La categoria Archiviazione, probabilmente la più importante delle quattro, include test che verificano la conformità delle soluzioni di archiviazione ai nuovi requisiti previsti per Cluster di failover di Windows Server 2008.

In particolare, oggi i fornitori hardware devono utilizzare driver basati sul driver Microsoft Storport e devono supportare le prenotazioni permanenti SCSI-3. Inoltre, se utilizzati, i moduli specifici per dispositivi Microsoft Multi-Path devono basarsi sullo standard I/O a percorsi multipli di Microsoft.

Grazie all'inclusione del processo di convalida, il modello di supporto è cambiato. Tutto l'hardware deve avere il logo Windows Server 2008 e tutti i test di convalida devono essere superati. Le uniche eccezioni sono costituite dai cluster multisito, che dispongono di due enclosure di archiviazione distinti e separati (uno per ogni sito) e l'implementazione della replica continua cluster di Exchange Server 2007, che non utilizza nessun archivio condiviso.

Nuovo modello quorum

In Clustering di failover di Windows Server 2008 è cambiato anche il modello quorum. Nei sistemi più vecchi, quando sentiva la parola quorum, un amministratore pensava immediatamente a un disco condiviso in cui risiedevano la configurazione del cluster e alcuni file replicati. Era il singolo punto di errore nel cluster. Se si verificava un errore del disco quorum, il servizio cluster si arrestava e la disponibilità elevata andava perduta.

I cluster di server di Windows Server 2003 offrivano un secondo tipo di quorum chiamato "maggioranza dei nodi". In genere, questo tipo di quorum veniva implementato nei cluster multisito e non richiedeva alcun archivio condiviso. Il quorum maggioranza dei nodi era composto da una condivisione file residente nell'unità di sistema di ogni nodo cluster. Le connessioni a questo tipo di quorum avvenivano tramite le connessioni SMB (Server Message Block). Ancora una volta, perché il cluster potesse funzionare era necessario che partecipasse una maggioranza di nodi.

Poi, grazie all'introduzione della replica continua dei cluster di Exchange Server 2007, ai cluster di server di Windows Server 2003 è stata aggiunta la funzionalità Witness di condivisione file. Questo ha fatto sì che un solo nodo cluster di replica continua cluster di Exchange 2007 (o qualunque cluster multisito) potesse continuare a fornire i servizi, a condizione che una connessione al witness di condivisione file raggiungesse una maggioranza.

In Clustering di failover di Windows Server 2008, l'idea di quorum significa veramente consenso. Il quorum, o consenso, oggi viene ottenuto con il raggiungimento di un numero sufficiente di voti per avviare il servizio del cluster e, a seconda della configurazione del quorum, i modi per ottenere il numero di voti necessario sono diversi. In un cluster di failover di Windows Server 2008 sono disponibili quattro modalità di quorum, come illustrato nella Figura 4. Dei quattro modi elencati, soltanto i primi due (Maggioranza dei nodi e Maggioranza dei nodi e dei dischi) possono essere selezionati automaticamente durante il processo di creazione del cluster. Questa è la logica da applicare:

• se nel cluster si configura un numero dispari di nodi, selezionare la modalità Maggioranza dei nodi;
• se nel cluster si configura un numero pari di nodi e l'archivio condiviso è connesso e accessibile, selezionare Maggioranza dei nodi e dei dischi.

Figura 4 Modalità dei quorum nella Configurazione guidata quorum del cluster (fare clic sull'immagine per ingrandirla)

Per selezionare un disco witness dall'archivio disponibile, selezionare il primo disco con dimensioni pari almeno a 500 MB e per il quale sia configurata una partizione NTFS. Le modalità quorum rimanenti possono essere selezionate solo manualmente eseguendo la Configurazione guidata quorum del cluster. In genere, l'opzione Maggioranza dei nodi e delle condivisioni file viene utilizzata in una configurazione di cluster multisito oppure in un cluster di replica continua cluster di Exchange 2007. L'ultima opzione, la modalità Non di maggioranza - solo disco, equivale al modello quorum condiviso nei cluster legacy. È un singolo punto di errore e in genere non andrebbe utilizzata.

Per contribuire al raggiungimento del consenso, esistono solo due tipi di risorsa witness che possono essere configurati nel cluster: un disco fisico e una condivisione file.

Un disco witness è una porzione di archivio di cui il servizio cluster può eseguire la connessione in linea. Questo disco si trova nel gruppo Risorse principali del cluster insieme al Nome rete del cluster e alle risorse di indirizzo IP associate. Quando si configura il disco witness, nel disco vengono inserite la cartella Cluster e una copia completa della configurazione del cluster (la replica o l'hive del cluster).

Un witness di condivisione file è una condivisione di rete che, nella situazione ideale, si trova in un server nella rete che non fa parte del cluster. Viene eseguita una connessione SMB al witness di condivisione file, il quale mantiene una copia del file di registro witness, che contiene le informazioni sul controllo versioni della configurazione del cluster.

In un cluster può essere configurata soltanto una risorsa witness. Alla risorsa spetta il compito di fornire un voto in più nel caso in cui il cluster ne avesse bisogno per raggiungere il quorum. In altre parole, se al cluster manca un voto (e perciò un nodo) per raggiungere il consenso, la risorsa witness si connette al fine di ottenere il quorum. Nel caso in cui al cluster mancasse più di un voto per raggiungere il quorum, la risorsa witness non viene coinvolta e il cluster rimane in uno stato di inattività, nell'attesa che un altro cluster esegua l'accesso.

Miglioramenti delle funzionalità di sicurezza

Cluster di failover offre diversi nuovi miglioramenti della sicurezza. Di maggior rilievo è forse quello che riguarda l'eliminazione del requisito dell'account del servizio cluster (CSA). Nelle versioni precedenti di Servizio cluster di Microsoft, durante il processo di configurazione era necessario un account utente di dominio. Utilizzato per avviare il servizio cluster, l'account veniva aggiunto al gruppo di amministratori locale di ciascun nodo del cluster e gli venivano assegnati i necessari diritti utente locale per consentire al servizio cluster di funzionare correttamente. Come account utente di dominio, il CSA doveva rispettare numerosi criteri a livello di dominio che potevano essere applicati ai nodi del cluster. Erano criteri che potevano avere un impatto negativo sulla disponibilità elevata, provocando errori del servizio cluster.

Oggi il servizio cluster viene eseguito utilizzando un account di sistema locale, con un set specifico di diritti nel nodo cluster locale che gli permette di funzionare correttamente. Il contesto della sicurezza del cluster è passato all'oggetto nome cluster (CNO), ovvero l'oggetto computer creato per impostazione predefinita nel contenitore Computer di Active Directory® quando si crea il cluster. Una volta riuscita la creazione del cluster e in Active Directory esiste il CNO, l'account utente utilizzato per installare e configurare il cluster non è più necessario.

Gli ulteriori oggetti computer creati nel contenitore Computer di Active Directory vengono associati a un cluster di failover. Questi oggetti, detti oggetti computer virtuale (VCO), equivalgono alle risorse Nome rete create nel cluster come parte dei punti di accesso client. Il CNO, cui si deve la creazione di tutti i VCO di un cluster, viene aggiunto all'elenco di controllo di accesso di sistema (SACL) dell'oggetto in Active Directory (vedere la Figura 5).

Figura 5 Sicurezza per un VCO in Active Directory (fare clic sull'immagine per ingrandirla)

Il CNO è anche responsabile della sincronizzazione delle password di dominio di tutti i VCO che ha creato. Questo processo viene eseguito in conformità ai criteri di rotazione delle password configurati per il dominio. Inoltre, poiché il CNO è responsabile della creazione di tutti gli oggetti computer associati ai VCO in un cluster, il CNO (Account del computer) deve disporre a livello di dominio del diritto di creare oggetti computer nel contenitore in cui vengono creati i VCO (per impostazione predefinita, il contenitore Computer).

Ulteriore innovazione, Kerberos ora viene utilizzato come metodo di autenticazione predefinito. L'esistenza di account del computer in Active Directory tiene conto di questa funzionalità di sicurezza avanzata. Tuttavia, il cluster ha anche la possibilità di utilizzare l'autenticazione con il protocollo NTLM (NT LAN Manager), nel caso in cui un'applicazione non in grado di utilizzare Kerberos avesse la necessità di accedere alle risorse cluster.

Sono più sicure anche le comunicazioni tra i nodi di cluster che interagiscono direttamente con il processo cluster. Per impostazione predefinita, tutte le comunicazioni interne a un cluster sono firmate. Tramite l'interfaccia della riga di comando cluster.exe, questa proprietà del cluster può essere modificata per fare in modo che tutte le comunicazioni tra i nodi siano crittografate così da aggiungere un ulteriore livello di sicurezza.

Estensione della funzionalità di connessione in rete

Le nuove funzionalità di connessione in Cluster di failover assicurano una maggiore flessibilità durante la progettazione delle soluzioni a disponibilità elevata e per il ripristino di emergenza. Allo stesso tempo, i miglioramenti alla connessione forniscono una connettività più affidabile tra i nodi del cluster.

Probabilmente, la funzionalità personalizzata più richiesta è stata la possibilità di individuare i nodi del cluster nelle reti separate. Oggi questo è possibile. Il driver della rete di cluster è stato completamente riscritto, così da fornire comunicazioni estremamente affidabili e a tolleranza d'errore tra i nodi di un cluster, a condizione che ciascuno di essi sia connesso ad almeno due reti separate e instradate in modo distinto.

Il driver della rete di cluster crea la propria tabella di routing interna sulla base delle informazioni di connettività fornite durante il processo di avvio del cluster. Ciò include le informazioni di connettività locale, oltre alle informazioni fornite nel database di configurazione cluster (hive del registro del cluster).

Parte del processo di convalida del cluster include un processo di rilevamento della connettività di rete. Il fatto di poter individuare i nodi del cluster su reti diverse e instradate ha mitigato i requisiti di connessione per i cluster multisito. Questo renderà più facile e meno onerosa la loro distribuzione da parte delle organizzazioni. Inoltre, renderà più appetibile l'uso dell'archivio iSCSI come soluzione di archiviazione in Cluster di failover.

I nodi di cluster possono ottenere le informazioni sugli indirizzi IP anche tramite DHCP (Dynamic Host Configuration Protocol). Si tratta di un protocollo capace di alleviare il carico di lavoro degli amministratori di rete, qualora riescano ad accettare l'uso dell'indirizzamento dinamico per i server nel loro ambiente.

È la configurazione delle interfacce di rete di un nodo del cluster a stabilire quali reti utilizzeranno gli indirizzi IP statici o quelli dinamici. Anche se viene ricavata da un server DHCP, una risorsa indirizzo IP in un cluster può essere trasformata in indirizzo IP statico nello snap-in Gestione cluster di failover.

In passato, tutte le informazioni relative ai cluster utilizzavano il broadcast UDP (User Datagram Protocol) e, a volte, il multicast. La funzionalità Multicast è stata interrotta e le comunicazioni tra cluster ora si avvalgono della trasmissione unicast UDP. (La porta 3343 è ancora la porta comune utilizzata dai cluster Microsoft). Molti amministratori di rete saranno felici di scoprire che la trasmissione broadcast non viene più utilizzata. Tuttavia, il vero vantaggio in un cluster ha a che fare con i nuovi processi di messaggistica che sono interni al servizio cluster, un aspetto che però esula dall'argomento del presente articolo. Oggi, le comunicazioni interne a un cluster sono caratterizzate da comunicazioni TCP più affidabili, sebbene utilizzino UDP come meccanismo di trasporto.

Maggiore affidabilità nell'interazione con l'archivio

Il modo in cui Cluster di failover interagisce con l'archivio differisce in modo radicale. Il driver del disco cluster (clusdisk.sys) è stato completamente riscritto e ora è un driver PnP (Plug and Play) vero e proprio. Inoltre, è cambiato il modo in cui interagisce con l'archivio.

In Windows Server 2003, il driver del disco cluster si trovava in un percorso diretto per l'archivio. Ma in Windows Server 2008, per interagire con l'archivio, il driver del disco cluster comunica con il driver del Gestore partizioni (partmgr.sys). Questi due diversi approcci sono illustrati nella Figura 6.

Figura 6 Come è cambiato lo stack di archiviazione in Windows Server 2008 (fare clic sull'immagine per ingrandirla)

Al Gestore partizioni spetta il compito principale di proteggere le risorse del disco cluster. Tutti i dischi in un bus di archivio condiviso sono automaticamente messi non in linea quando vengono associati a un nodo di cluster. Questo consente all'archivio di essere associato simultaneamente a tutti i nodi di un cluster, anche prima che il cluster venga creato. Non è più necessario avviare i nodi uno alla volta, preparare i dischi in un nodo e poi arrestarlo, quindi avviare un altro nodo, verificare la configurazione dei dischi e così via.

Tuttavia, sono ancora presenti i test dell'archivio, che vengono eseguiti nel contesto del processo di convalida del cluster e richiedono l'inizializzazione dei dischi. Ciò può avvenire in uno dei nodi del cluster prima dell'esecuzione del processo di convalida. Una volta che l'archivio è stato aggiunto al cluster, nell'interfaccia Gestione disco i dischi mostrano lo stato Riservato e non sono mai lasciati in uno stato non protetto.

Un altro cambiamento riguarda i comandi SCSI. In Windows Server 2003, venivano utilizzati i comandi di prenotazione/rilascio SCSI-2 con il driver del disco cluster che scriveva in settori del disco stesso. In Windows Server 2008, sono necessari comandi di prenotazione permanente SCSI-3. I nodi di cluster devono registrarsi prima che sia consentito loro di effettuare una prenotazione dell'archivio e periodicamente devono difendere le prenotazioni utilizzando il protocollo RDP (Reservation and Defense Protocol).

Nell'ambito del processo di convalida, uno dei test verifica questa funzionalità. Se una soluzione di archiviazione non supporta i comandi di prenotazione permanente SCSI-3, non è supportata in un cluster di failover.

Per la ridondanza, quando si connettono all'archivio molte organizzazioni utilizzano software a percorsi multipli. Questa soluzione è non solo supportata ma persino promossa come procedura consigliata. Tuttavia, perché siano supportati in un cluster di failover, le soluzioni software a percorsi multipli di terze parti o i moduli specifici per dispositivi devono essere riscritti utilizzando lo standard I/O a percorsi multipli di Microsoft. Questo assicura che tutti i comandi di prenotazione permanente SCSI-3 siano inviati contemporaneamente in tutti i percorsi per l'archivio, indipendentemente dal fatto che il percorso sia attivo o meno. Anche questa funzionalità viene verificata nell'ambito del processo di convalida.

Tra gli altri miglioramenti dell'archivio sono da ricordare un processo avanzato di controllo del disco (chkdsk.exe), la funzionalità incorporata di ripristino dischi (in precedenza parte dell'utilità di ripristino del server) e i dischi con riparazione automatica. In Cluster di failover, quando si identifica una risorsa disco cluster, vengono utilizzati sia la firma del disco che l'ID LUN. Se uno dei due è cambiato, viene aggiornata la configurazione del cluster. Il risultato è una riduzione degli errori, semplicemente in virtù del fatto che la modifica di un attributo in una risorsa disco produce una maggiore disponibilità elevata.

Processi di ripristino incorporati

La riparazione automatica dei dischi è ovviamente una delle funzionalità di ripristino incorporate. Un'altra è la funzionalità Ripristina di Active Directory. Se l'oggetto computer che rappresenta il CNO viene eliminato, non è più possibile creare gli oggetti computer associati ai punti di accesso client del cluster. Tuttavia, con ogni probabilità il primo problema a verificarsi sarà l'impossibilità degli utenti o delle applicazioni a disponibilità elevata ad accedere alle risorse esterne al cluster, poiché non riescono a ottenere un token di protezione.

Per ripristinare un CNO eliminato è necessario eseguire un processo che richiede due passaggi. Innanzitutto, si deve richiedere a un amministratore di dominio di recuperare l'oggetto computer eliminato dal contenitore DeletedObjects di Active Directory. Quindi, dopo il ripristino e la riattivazione dell'oggetto, si dovrà eseguire il processo Ripristina oggetto Active Directory nello snap-in Gestione cluster di failover.

Nei cluster di server di Windows Server 2003, esisteva la possibilità che il file di configurazione cluster contenuto nella sottodirectory %systemroot%\cluster si potesse danneggiare e pertanto dovesse essere sostituito. In Cluster di failover, la funzionalità di riparazione automatica può risultare utile in questo senso. Se il servizio cluster viene avviato in un nodo e il database di configurazione è danneggiato, verrà caricato un modello di configurazione minima che utilizza le informazioni contenute nella chiave del registro di sistema HKLM\System\CCS\Services\ClusSvc\Parameters. Il nodo tenterà di accedere a un cluster già formato e, se il tentativo riesce, al nodo viene inviata una nuova copia dell'hive del registro del cluster. Al contrario, se il nodo non riesce ad accedere a un cluster, il servizio cluster sarà terminato.

Nuova funzionalità di backup e ripristino

Clustering di failover è dotato del proprio writer del servizio Copia Shadow del volume. Questo svolge un ruolo fondamentale nelle operazioni di backup e ripristino del database di un cluster e dei dati che risiedono nelle risorse del disco fisico. Il backup della configurazione del cluster è un'operazione piuttosto semplice. Purché lo stato del sistema faccia parte di un backup, la configurazione del cluster può essere ripristinata. Ma occorre tenere presente che si deve eseguire il backup di un cluster soltanto se ha il quorum. Questo assicura che il backup venga effettuato sulla configurazione più aggiornata del cluster.

Esistono due tipi principali di ripristino: autorevole e non autorevole. Da una parte, un ripristino non autorevole utilizza Windows Server Backup o un'applicazione di backup di terze parti per eseguire un ripristino da un backup selezionato. Dall'altra, un ripristino non autorevole di un nodo di cluster può essere effettuato soltanto utilizzando l'interfaccia della riga di comando di Windows Server Backup (wbadmin.exe).

In pratica, un ripristino autorevole riporta la configurazione del cluster "indietro nel tempo" fino al momento in cui è stato eseguito il backup. Per realizzare un ripristino di questo tipo, il servizio cluster si arresta in tutti i nodi ad eccezione di quello in cui viene eseguito il ripristino. Una volta terminato il ripristino e riavviato il servizio cluster nel nodo ripristinato, la configurazione ripristinata del cluster diventa la nuova configurazione definitiva. Successivamente, quando si riavvia il servizio cluster nei nodi rimanenti del cluster, la configurazione ripristinata viene trasferita durante il processo di accesso.

In alcuni scenari, questo consente di ottenere risparmi notevoli in termini di tempo e di denaro. Poniamo di avere un cluster di stampa che ospita più risorse di spooler di stampa, ognuna delle quali supporta 1.500 stampanti, e che accidentalmente venga eliminata una di tali risorse. Questo significa che un consistente numero di utenti non può stampare. Anziché aggiungere manualmente tutte le stampanti alla configurazione del cluster, sarebbe molto più veloce eseguire un ripristino autorevole di quella configurazione. Ma questo, naturalmente, dipende dalla disponibilità sia di un backup affidabile che di una strategia di ripristino.

Migrazione dai cluster di server di Windows Server 2003

A causa di tutte queste modifiche dell'architettura apportate in Clustering di failover di Windows Server 2008, non sono supportati gli aggiornamenti sul posto o in sequenza da Windows Server 2003. Quando si esegue l'aggiornamento dai cluster Windows Server 2000 a Windows Server 2003, molte organizzazioni rimuovevano sistematicamente ogni nodo del cluster, eseguivano un'installazione pulita del sistema operativo e quindi aggiungevano nuovamente il nodo nel cluster. Non è possibile utilizzare lo stesso approccio per la migrazione a Windows Server 2008, dal momento che i nodi di cluster di Windows Server 2003 e quelli di Windows Server 2008 non possono appartenere allo stesso cluster.

Fortunatamente, per facilitare le operazioni è stato incluso un processo di migrazione tramite procedura guidata. Tuttavia, la migrazione a Cluster di failover di Windows Server 2008 richiede comunque una pianificazione. Si presentano tre scenari di base per la migrazione:

• uso degli stessi server e dello stesso archivio;
• uso degli stessi server, ma con un archivio nuovo;
• uso di nuovi server e di un nuovo archivio.

Tutti gli scenari richiedono che l'hardware abbia ottenuto la certificazione del programma Windows Logo Program di Windows Server 2008, che sia stato eseguito il processo di convalida di Cluster di failover e che tutti i test siano stati superati. Una volta completati questi passaggi, il processo di migrazione può procedere.

Non è possibile eseguire la migrazione di tutte le risorse in Windows Server 2003. La si può eseguire per nomi di rete, indirizzi IP, dischi fisici, condivisioni file, directory principali DFS (Distributed File Share), DHCP e WINS. Lo stesso vale, con qualche limitazione, per servizi generici, applicazioni generiche e risorse script generici.

Applicazioni quali Microsoft Exchange ed SQL Server® dispongono delle proprie procedure per la migrazione a Cluster di failover. Quanto alle stampanti, se ne può eseguire la migrazione a Windows Server 2008 utilizzando lo snap-in Gestione stampa (che è installato con il ruolo di server di stampa) prima per esportare e poi per importare le stampanti in un server di stampa a disponibilità elevata e recentemente configurato. Non è possibile eseguire la migrazione di nessun tipo di risorsa di terze parti.

Il processo di migrazione non trasferisce dati, bensì è riservato alla migrazione delle impostazioni di configurazione del cluster da Windows Server 2003 a Windows Server 2008.

All'inizio, tutte le risorse oggetto di migrazione vengono messe non in linea una volta completato il processo di migrazione. Questo perché potrebbero essere richiesti ulteriori passaggi. Pertanto, prima di mettere in servizio il cluster, è importante leggere il report post-migrazione per vedere i passaggi aggiuntivi richiesti (esclusa la migrazione dei dati se si esegue la migrazione a un nuovo archivio). Ad esempio, se si esegue la migrazione di un server DHCP, sarà necessario installare il ruolo di server DHCP in tutti i nodi del cluster. Se si esegue la migrazione di un server WINS, sarà necessario installare la funzionalità Server WINS in tutti i nodi del cluster.

Chuck Timon è Support Escalation Engineer per Microsoft a supporto delle tecnologie di clustering e installazione. Ha scritto il corso di formazione per Windows Server 2008 Failover Cluster e attualmente è al lavoro sul corso di formazione per Hyper-V.

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