Configurare WSUS in modalità NLB

Il servizio WSUS in modalità NLB è una buona soluzione per bilanciare il carico sul server e permettere di gestire il patching dei client a costi ridotti.

Con il periodo nero dell'economia mondiale, le aziende stanno facendo un massiccio "cost saving" per arginare i bilanci sempre più critici. Purtroppo il settore IT è quello che più ne fa le spese con pesanti tagli sul budget di investimento informatico.

Le nuove soluzioni da proporre al management per la gestione e implementazione dei sistemi IT sono per il momento da tenere nel cassetto in attesa di tempi migliori... che fare allora? E' qui che sta anche la bravura dei sistemisti... trovare soluzioni funzionali risparmiando drasticamente sui costi.

Ed ecco che si riafferma, soprattutto per le PMI, una tecnologia per la gestione clients che, onestamente, ho sempre ritenuto efficace: WSUS. Tecnologia Microsoft, WSUS è una soluzione molto valida per la gestione dei sistemi di rete che permette di mantenere un parco macchine aggiornato limitando notevolmente i costi di implementazione e amministrazione poichè non prevede nessuna licenza di utilizzo.

 

Definire l'ambiente operativo

Naturalmente per avere questo servizio con determinati standard funzionali, WSUS deve essere opportunatamente configurato in modo da garantire la continuità del servizio (cluster) e prestazioni di rete adeguate (Network Load Balancing) per meglio distribuire il carico del server destinato a svolgere questo ruolo. Per evitare confusione è bene specificare che WSUS in modalità cluster non ha molto senso... è ben più utile per SQL ed Exchange invece.

Prima di procedere con l'installazione di WSUS, bisogna definire l'ambiente operativo per rispettare i termini di continuità e di prestazioni del servizio. Per fare in modo che il servizio sia fault tolerant e per evitare l'overload del server, il database di WSUS (SUSDB) viene "appoggiato" ad un server SQL configurato in modalità cluster mentre WSUS viene installato su un server in modalità NLB. Oggi giorno quasi tutte le aziende sono dotate di uno storage SAN dedicato ai sistemi "core" come Exchange e SQL. Quindi una valida soluzione può essere l'utilizzo di un LUN dedicato del SAN per rendere accessibili in remoto gli aggiornamenti di WSUS.

 

Prerequisiti

WSUS richiede per la sua installazione i seguenti requisiti:

• IIS 6.0
• Microsoft .NET Framework v2.0 Redistributable Package
• Microsoft Report Viewer Redistributable 2005
• WSUS SP1

 

Configurare SQL Server 2005 per WSUS

Prima di procedere con l'installazione, è necessario configurare il cluster SQL in modo da operare correttamente con quanto richiesto da WSUS.

L'utente utilizzato per l'installazione di WSUS ha i diritti di amministratore sul Server SQL.

Per verificare, aprire SQL Server Management Studio, fare click col tasto destro sul server nell'Object Explorer e selezionare Properties.

In Advanced, impostare l'opzione Allow Triggers to Fire Others come True (default) o False.

Windows Authentication deve essere utilizzata in SQL. WSUS supporta solo questa modalità.

Il servizio Remote SQL Connections deve essere impostato come TCP/IP only.

Ricordarsi di specificare come Remote computer da configurare il nome del server virtuale SQL (sqlcluster nella figura) poichè è configurato come cluster.

L'account utilizzato per installare il database utilizzato da WSUS (SUSDB) in SQL deve essere presente in Security -> Login.

 

Registrazione SPN

Un parametro fondamentale per il corretto funzionamento dell'accesso remoto al database SQL è la registrazione del service principal name (SPN) per questo server. Senza questa impostazione, si avranno problemi di autenticazione Kerberos e quindi WSUS non riuscirà a stabilire la connessione con il database e i clients non riusciranno a connettersi.

Per effettuare la registrazione di SPN è necessario il tool setSPN.exe che è presente nei Support Tools di Windows Server 2003. Procedere in questo modo:

Installare i Support Tools in un qualsiasi server di dominio e logarsi come Domain Admin.

es. setspn -A MSSQLSvc/sqlcluster:1433 sqlservice

Riavviare il server SQL dopo che la replica AD è stata effettuata.

Per verificare che SPN è stato correttamente registrato, dal command prompt eseguire:

C:\> setspn -L <SQL_Service_Account>

E' possibile verificare o editare questo parametro utilizzando ADSI Editor che è sempre presente nei Support Tools.

Per verificare che SQL stia effettivamente funzionando con l'autenticazione Kerberos, eseguire la seguente query nel server SQL:

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Il risultato deve riportare KERBEROS, come illustrato nella figura.

 

Installazione di WSUS

Installare il primo WSUS server in modo da creare il database SUSDB nel server SQL. Dal command prompt eseguire il programma di installazione:

C:\> WsusSetup.exe SQLINSTANCE_NAME=server\instance

Se viene utilizzata l'istanza di default di SQL, specificare solo il nome del server. Per installare altri WSUS front-end servers, eseguire dal command prompt:

C:\> WsusSetup.exe /q FRONTEND_SETUP=1 SQLINSTANCE_NAME=server\instance CREATE_DATABASE=0 DEFAULT_WEBSITE=0

Viene installato solo il front-end di WSUS connesso al database SUSDB (precedentemente creato) nel cluster SQL con la porta web impostata su 8530. Una volta terminata l'installazione, l'applicazione richiede la definizione dei parametri operativi (proxy, prodotti, etc.).

 

Configurare l'area di sharing

Poichè più front-end devono accedere gli stessi contenuti, una buona soluzione può essere l'utilizzo di un LUN dedicato dello storage SAN per salvare i contenuti di WSUS. Naturalmente una qualsiasi area condivisa (Network Share, DFS) è adatta allo scopo.

Appoggiandosi ad un SAN, è necessario installare Microsoft iSCSI nei servers utilizzati per WSUS NLB per assegnare l'area condivisa definendo il disco dedicato (nella figura è indicato come W:\).

 

Spostare il contenuto di WSUS nell'area di share

Per spostare il contenuto delle directory di sistema di WSUS nell'area di share (SAN in questo caso), è necessario spostare il contenuto dalle directory locali tramite il comando:

C:\> cd \Program Files\Update Services\Tools\wsusutil movecontent sharename logfilename

es. wsusutil movecontent W:\ movelogresult)

Il risultato, come illustrato nella figura, è la creazione delle directory con gli aggiornamenti di WSUS.

 

Configurare IIS per i server front-end

Per accedere agli aggiornamenti nell'area condivisa, i server WSUS front-end devono avere IIS configurata opportunamente per permettere l'accesso remoto.

Tramite IIS Manager, impostare l'accesso all'area condivisa.

 

Configurare NLB

A questo punto è finalmente possibile configurare NLB. Poichè la documentazione in Internet su come implementare NLB è ampia e facilmente reperibile, non viene illustrata in questo articolo.

Terminata la procedura, effettuiamo un check per verificare che NLB sta funzionando. Dal command prompt eseguire il comando nlb query.

Verificati che gli host coinvolti in NLB hanno uno stato CONVERGED, il cluster NLB è operativo e funzionante.

 

Configurare WSUS client

Poichè i clients sono generalmente configurati tramite GPO, il parametro utilizzato per identificare l'Intranet update service location deve essere l'indirizzo del Web virtuale (nlbcluster). nlbcluster è il DNS name del cluster NLB.

 

Testare WSUS

Naturalmente prima di mettere in produzione il servizio WSUS con questa configurazione, è opportuno testare il tutto con pochi clients o meglio in un ambiente di LAB per evitare spiacevoli sorprese e forti mal di testa.