Archive

Windows Server 2008

Lotus Domino 8.5 è ufficialmente certificato su Windows Server 2008. E la cosa non mi dispiace visto che i clienti con l’ultima versione di Domino potranno utilizzare questo fantastico sistema operativo (scusate le lodi sperticate secondo me meritatissime).

Advertisements

Per una serie di motivi in questi giorni mi sono trovato personalmente coinvolto nella vendita e nell’installazione di un sistema di virtualizzazione basato su diversi prodotti hardware IBM e software Microsoft. In particolare abbiamo costruito e configurato un sistema a doppio server IBM x3655 con uno storage IBM DS4700 (in tecnologia Fibre Channel ovviamente) con un elevato livello di ridondanza per garantire alte affidabilità e continuità. Al tutto è stato aggiunto un tape storage IBM TS3100 con unità LTO3.

Installare l’hardware e configurarlo è stato (relativamente) molto semplice. Mi ha particolarmente impressionato lo storage DS4700 con l’ultima revisione del firmware in grado di supportare completamente Windows Server 2008 in cluster e con il supporto multipath nativo.

Ma visto che questo è un blog su Windows vorrei concentrarmi sull’aspetto del sistema operativo.

Per prima cosa abbiamo installato Windows Server 2008 Enterprise sulle due macchine. Poi, dopo i necessari aggiornamenti, abbiamo installato Hyper-V. Dopo aver configurato lo storage e aver agganciato alle macchine le partizioni logiche dello storage abbiamo lanciato il tool per la creazione del cluster (di failover): il wizard ha chiesto che macchine avrebbero fatto parte del cluster e ha lanciato una serie di test che hanno evidenziato alcuni errori di configurazione. Corretti velocemente questi problemi abbiamo rilanciato il wizard che in pochi minuti ha creato un sistema di cluster funzionante. Lasciatemi dire che rispetto a 2000/2003 è un bel miglioramento.

Visto la presenza di Hyper-V tra le risorse clusterizzabili esistono anche le macchine virtuali. Creare una macchina virtuale clusterizzata (quindi in grado di resistere al crash di uno dei nodi) è questione di pochi minuti. Ovviamente il solito wizard guida l’utente nell’operazione passo per passo.

La facilità di installazione e configurazione di tutto il sistema è veramente notevole.

Dopo aver fatto questo abbiamo installato il Data Protection Manager, la soluzione di backup di Microsoft. DPM (con l’SP1) ha riconosciuto immediatamente il tape storage IBM. In pochi minuti ha configurato il sistema di backup. Anche di questo mi ha stupito la semplicità.

E’ un dato di fatto che questa semplicità d’uso in pochi mesi ha convinto molti nostri clienti che, anche aiutati da noi, hanno deciso di montare 2008 e Hyper-V.

Pare che Windows Server 2008 R2 (detto anche la versione server  di Windows 7) sarà solo a 64 bit. E’ interessante notare che anche alcune versioni di prossimi pacchetti (stiamo parlando sempre di server) saranno solamente a 64 bit. E questo sia di Microsoft che di altri produttori.

Questa non è novità, comunque. Pensando al fatto di dover migrare, nei scorsi tre anni fino all’estate del 2007 non abbiamo più acquistato server perchè aspettavamo le “nuove” macchine e ci siamo arrangiati con dei serverini (in pratica dei grossi PC desktop). Ora il problema non sussiste dato che processori, hardware e firmware sono adeguati.

Sul lato desktop invece la situazione mi sembra più tranquilla, complice il fatto che molto hardware ancora non gestisce alcune caratteristiche che rendono veramente utili i 64 bit (ad esempio quanti portatili sono in grado di supportare più di 4GB di RAM?).

Detto questo è bene cominciare a pensare a come cambiare l’hardware e il software dei server nei prossimi anni.

Direi che, con le operazioni di ieri, la nostra migrazione a Windows Server 2008 è quasi completa. Rimangono solamente 2 server 2003 significativi ma con le sostituzioni già pronte: dovremo farlo un fine settimana per evitare interruzione del servizio.

In pratica il progetto prevedeva 3 aspetti fondamentali: sostituzione di alcuni vecchi (anche di 10 anni) server, consolidamento di altre macchine e migrazione a 2008. Gli step che abbiamo seguito sono semplici:

  • acquisto e installazione di una macchina adeguata per il supporto di Hyper-V;
  • aggiornamento del domain controller “principale” da 2003 a 2008;
  • installazione di una macchina di management con vari tool tra cui SCVMM 2008 (abbiamo iniziato con la beta e finito con la versione definitiva);
  • aggiornamento della RAM di una macchina preesistente per metterla in grado di supportare Hyper-V;
  • migrazione di diversi dei vecchi server sui 2 server Hyper-V (sto parlando di una serie di macchine, per lo più vecchi IBM Netfinity,  dove le più potenti avevano dei processori Pentium III);
  • migrazione dei server virtuali preesistenti da Virtual Server 2005 R2 a Hyper-V;
  • aggiornamento di alcuni di questi server virtuali da 2003 a 2008;
  • riconfigurazione e riposizionamento dei servizi di alcuni server su altri server.

Oltre a questo ieri ho anche proceduto personalmente a virtualizzare un client basato su XP. Su questo client ci sono tutta una serie di programm più o meno orribili ma di cui non si può fare a meno (quelli del ministero per trasmettere dati fiscali ad esempio) e che non avevo proprio nessuna voglia di reinistallare (o far reinstallare). Dopo i vari test dei prossimi giorni potrò eliminare la macchina fisica e sostituirla con una più moderna e basata su Vista.

SCVMM 2008 sì è rivelato molto utile per catturare questo tipo di macchine e trasformarle da fisiche a virtuali. E’ stato anche utile per spostare le macchine tra i due server Hyper-V e per avere una gestione unificata dei due ambienti. 

Per restare in tema abbiamo anche installato un Terminal Services Gateway (è una funzionalità di Windows Server 2008) e abbiamo esposto una serie di programmi. Questo ci permette di utilizzarli ovunque grazie al tunnel dell’RDP nel HTTPS. In altri termini si possono usare anche attraverso i firewall purchè ci sia un proxy HTTPS aperto (situazione pressochè generale).

image

Come sottoprodotto di questa migrazione abbiamo  liberato delle macchine vecchie ma relativamente potenti su cui sposteremo fisicamente alcune funzionalità dei server Linux più vecchi. Alcuni però verranno virtualizzati (penso al repository del codice Java, ad esempio).

Le prestazioni del sistema sono ottime, le impressioni di utilizzo sono molto buone e gli utenti hanno avuto fastidi minimi. La migrazione è stata funestata però dai problemi avuti nell’ultimo mese dalla rete elettrica generale della zona di Pordenone.

Dopo mesi di attesa, abbiamo finalmente deciso di acquistare un server per virtualizzare un po’ di sistemi. La macchina sarà un IBM xSeries 3850 M2, doppio xeon quadri core, tanta RAM e con un box esterno per i dischi.

Una delle caratteristiche più importanti è che la macchina è certificata per Windows Server 2008 e Hyper-V. Si tratta di un aspetto fondamentale che non può essere sottovalutato data la relativa complessità di queste soluzioni.

Su questa macchina gireranno diversi software e sistemi anche non Microsoft.

In un paio di post precedenti mi scagliavo contro chi virtualizzava qualsiasi cosa. Continuo ad essere della mia idea: alcuni servizi è bene abbiano macchine dedicate.

Oggi si è rotto uno dei domain controller della rete (tra l’altro quello master per i ruoli di AD).

In realtà il guasto è dovuto al fatto che il server si sentiva trascurato e voleva migrare a 2008. Alla fine, visto che non gli badavamo, ha deciso di rompersi. E così abbiamo dovuto ripararlo e aggiornarlo. 😉

Visto che c’eravamo l’ho fatto ripristinare creando una installazione ex-novo di Windows Server 2008. Ovviamente in rete c’erano altri Global Catalog. La nostra non è una azienda enorme e quindi questo server, oltre al DC, implementa ruoli di DHCP, Network Policy Server e Printer Sharing. La macchina è un vecchio server IBM xSeries 205, ha un P4 da 2.66 MHz e 1 GB di RAM. E nonostante queste scarse caratteristiche si comporta molto bene per i ruoli che ha.

La cosa divertente (!) che è capitata è il fatto che non si riusciva a configurare la porta (LPR) di una stampante di rete… per poi scoprire che il sistema visualizzava le stampanti di rete mappate localmente (e non più funzionanti) visibili sul server per via del fatto che si utilizzava remote desktop.