Archive

Windows Server 2008 R2

Abbiamo acquistato un nuovo portatile Lenovo T510. E la sensazione è la stessa del mio HP da casa: sistema operativo pulito e ben installato, macchina che risponde, pochi minuti per la prima partenza. Insomma una esperienza gratificante rispetto a quello che succedeva con i vecchi PC.

Nel contempo è anche arrivato un  monitor multitouch Acer T230H. Collegati i due cavi in pochi secondi era funzionante. Usare Windows 7 con un multitouch è interessante.

Infine in questi giorni abbiamo finito l’installazione di un IBM BladeCenter H con delle lame HS22 su una storage IBM DS4700 (con switch Brocade). Ovviamente con Windows 2008 R2 e Hyper-V. Al di là della quantità innominabile di firmware da installare e una lama guasta (subito sostituita dal servizio di assistenza), l’installazione è stata una esperienza fluida: solo 4 giorni di lavoro dalle apertura delle scatole alla messa in produzione.

Si vede che questi hardware sono progettati per questi software.

Notevole!

Advertisements

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

Il firewall presente in 7 e 2008 R2 è ben sofisticato.  E con un mucchio di regole. Se vi serve capire che porte e protocolli sono aperti e su quale profili sono attivati si devono analizzarle. Un modo per farlo con calma è dare il comando:

netsh advfirewall firewall show rule name=all >rules.txt

Poi con un editor si apre il file rules.txt e lo si visiona a piacere.

A grande richiesta abbiamo organizzato il 27 novembre 2009 alle 14.30 presso la nostra sede di Pordenone una round table (e probabilmente toccherà organizzarne una seconda) su 7 e 2008 R2. Per round table noi intendiamo un incontro con un numero limitato di persone che comprende almeno una presentazione sull’argomento seguita da una chiaccherata. Nel rispetto degli argomenti l’esecuzione è abbastanza a ruota libera (l’agenda è più un canovaccio). Di solito le nostre round table sono molto apprezzate.

Con questa, in particolare, vogliamo affrontare sia l’aspetto tecnico sia quello di acquisto (abbastanza ignoto purtroppo). Dal punto di vista tecnico affronteremo sia Windows 7 (meccanismi di deploy, compatibilità con Windows XP, sicurezza, altro) sia Windows Server 2008 R2 (Hyper-V, Remote Desktop Service, nuove funzionalità di rete). Dal punto di vista commerciale parleremo di come si acquista e delle offerte in atto.

Se siete dalle parti di Pordenone e volete partecipare scrivetemi.

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.