Archive

Windows Server 2008

In una rete Windows, solitamente le macchine sincronizzano l’orologio con il domain controller che simula il PDC. Una classica configurazione prevede quindi che il PDC sincronizzi l’orologio con un server NTP in Internet. In questo modo tutte le macchine sono coerenti.

Ieri mi è capitato un effetto interessante. Un cliente aveva il server con il ruolo PDC virtuale su un server virtuale ospitato in Hyper-V. Questo server virtuale si collegava ad un server NTP pubblico ma non riusciva ad sincronizzare l’orologio. Tutte le macchine del dominio avevano un orario più avanti di circa 15 minuti.

Il fatto è che una macchina ospitata solitamente utilizza una serie di servizi forniti dall’ipervisore. Tra questi vi sono i servizi di Time Synchronization che fanno si che la macchina sincronizzi l’orario sulla base di quello dell’ipervisore. Quindi se l’ipervisore ha un orario errato (era il nostro caso) anche le macchine ospitate che usano questi servizi avranno un orario errato. Cambiare l’orario in una macchina ospitata non sortisce alcun effetto.

Per risolvere il problema si possono seguire varie strade. Ad esempio si sposta il PDC su un server fisico e si fa in modo che questo si sincronizzi con il server NTP. Oppure si fa in modo che l’ipervisore si sincronizzi via NTP così, di conseguenza, le macchine virtuali ospitate avranno l’ora corretta (ma questo potrebbe provocare una retroazione). Oppure, soluzione da me scelta in questo particolare caso, si disabilita il servizio di Time Synchronization per la macchina virtuale che ha il ruolo di PDC.

image

La settimana scorsa siamo impazziti. Un cliente ha acquistato due nuovi IBM System x x3650 M2 destinati a costruire un cluster Hyper-V R2 su una SAN basata su uno storage IBM DS4700. Queste macchine non hanno più un BIOS all’interno ma hanno un nuovo firmware UEFI. UEFI gestisce il boot in modo differente e Windows 2008 R2 lo supporta pienamente.

Arrivate le macchine si è proceduto alla creazione di un volume RAID1 usando la funzionalità di management incorporata in UEFI. Poi si è efffettuata l’installazione del sistema operativo direttamente dal disco di Windows 2008 R2 (senza utilizzare ServerGuide che, al momento, non supporta ancora R2). E fin qui è andato tutto bene.

In seguito sono state collegate le schede in fibra QLogic e si sono associate 2 LUN (quorum + spazio per le macchine virtuali). Al reboot i sistemi non caricavano più il sistema operativo dal disco ma tentavano il boot dalla prima LUN (ovviamente senza riuscirci visto che non c’era nessun sistema operativo sopra).

Dopo vari tentativi alla fine la soluzione è stata quella di abilitare come primo device di boot quello Legacy (in pratica una emulazione del vecchio sistema BIOS) e reinstallare tutto. Fatto questo i sistemi hanno funzionato come dovevano e in poco tempo l’Hyper-V R2 in cluster (con CSV) è stato attivato.

La cosa più snervante sono stati i tempi di boot del firmware tra una prova e l’altra. In generale questo tipo di macchine sono lente visto la diagnostica che effettuano ma UEFI aumenta ulteriormente il tempo. Si fa prima a fare il boot di Windows che il boot del firmware! E questo dimostra che per avere PC veloci nel boot, anche i produttori di firmware devono fare la loro parte.

Oggi, parlando con il mio socio, è saltata fuori la storia di un cliente che voleva virtualizzare un server operativo creando un PC virtuale da quello fisico, lavorare sulla macchina fisica e ricreare la macchina fisica da quella virtuale. In pratica un processo di virtualizzazione seguito da uno di devirtualizzazione. Il mio socio chiedeva a me che strade si potevano seguire.

Dopo aver detto che si poteva fare in vari modi ho subito aggiunto che non valeva la pena di farlo. Conveniva invece virtualizzare e lasciare il server virtualizzato.

In pratica quello che ho suggerito era di far girare la singola macchina virtuale su un singolo server fisico dedicato. Questa operazione ha un costo irrisorio, sia in termini di prestazioni che di risorse, ma permette di raggiungere il più grande vantaggio della virtualizzazione: l’indipendenza dal ferro!

L’indipendenza dal ferro significa soprattutto la possibilità di modulare l’hardware in base alle mutate esigenze senza stravolgere la parte software dei sistemi. In questo modo si aumenta anche la longevità della soluzione.

Questo modello di virtualizzazione singola macchina è già noto in diversi ambienti operativi ed io lo trovo particolarmente efficace.

Il risultato su PC Intel/AMD si può raggiungere usando vari virtualizzatori. Anche utilizzando l’infrastuttura Microsoft basata su Hyper-V: non molti lo sanno ma esiste anche Microsoft Hyper-V Server 2008. Si tratta di una versione stand-alone che non include Windows Server 2008  e che è gratuita, seppure con qualche limite in più. Non l’ho ancora provato (conto di farlo quanto prima) ma suppongo funzioni bene come il fratello inserito in Windows 2008.

Ovviamente occorre verificare che la soluzione che si intende virtualizzare sia supportata (oggi la situazione è migliore di qualche mese fa ma ci possono essere sorprese) e occorre verificare la situazione relativa alle licenze utilizzate nel sistema guest. Riguardo a questo ultimo punto vi consiglio di stare molto attenti perchè neppure molti commerciali di diversi vendor hanno le idee chiarissime e se vi si richiede una verifica della compliance potreste trovarvi nei problemi.

L’altra domenica volevo installare Windows 7 sul mio vecchio tablet pc ma avevo un problema: il tablet non aveva una unità per i DVD e non supportava il boot da USB.

Per aggirare il problema, sul mio media center basato su Windows Vista Ultimate ho creato una macchina virtuale (da 1GB di RAM) utilizzando Virtual PC . Sulla questa macchina virtuale ho installato Windows Server 2008 Standard, AD, DHCP e i servizi di deploy di Windows (WDS). Ci ho copiato sopra il contenuto del DVD di 7 e ho configurato il WDS in modo da usarlo per l’installazione via rete. Ho temporaneamente disattivato il DHCP del router che uso a casa (per evitare conflitti con il DHCP di 2008 ) e ho attivato il boot da rete (PXE) nel BIOS del tablet. Fatto ripartire il tablet nel giro di pochi secondi l’installatore di 7 era attivo. Un’altro po’ di tempo e 7 era installato.

Divertente!