Numero speciale: Windows Server 2008

Le novità del kernel di Windows Server 2008

Mark Russinovich

 

Panoramica:

• Gestione della memoria e SMB 2.0
• Riparazione automatica di NTFS, Windows Hardware Error Architecture e il verificatore driver
• Scalabilità con le porte di completamento I/O, i pool di thread e NUMA
• Virtualizzazione Hyper-V

Windows Server 2008 è la versione più recente della piattaforma server di Microsoft e contiene novità a livello di sistema in ogni area funzionale del sistema operativo, dalla gestione della memoria

alla pianificazione dei thread e dalla connessione in rete alla protezione, per citarne solo alcune.

Poiché condivide lo stesso kernel di Windows Vista® SP1, Windows Server® 2008 contiene molti dei miglioramenti che ho già descritto nei miei articoli precedenti di TechNet Magazine: "Il kernel di Windows Vista" parti da 1 a 3 (febbraio, marzo e aprile 2007) e "Controllo dell'account utente di Windows Vista" (giugno 2007). Solo alcune delle funzionalità descritte in quegli articoli sono esclusivamente indirizzate ai client e non presenti in Windows Server 2008, come SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot e il Servizio Utilità di pianificazione classi multimediali (MMCSS).

Piuttosto che ripetere le informazioni sulle novità importanti del kernel di Windows Vista disponibili anche in Windows Server 2008, come la determinazione delle priorità di I/O, la nuova architettura dell'avvio, BitLockerTM, l'integrità del codice e i livelli di integrità obbligatori, qui si preferisce appuntare l'attenzione sulle novità principali non illustrate in quegli articoli, tra cui alcune relative ad affidabilità, prestazioni, scalabilità, oltre alla nuova tecnologia di virtualizzazione hypervisor di Microsoft, Hyper-VTM.

Inoltre, come negli articoli precedenti, l'ambito resta limitato al kernel del sistema operativo, Ntoskrnl.exe, oltre che ai componenti di sistema più strettamente associati. In questo articolo non vengono illustrate, ad esempio, le modifiche apportate all'installazione (WIM o Windows® Imaging Format e il modulo di manutenzione pacchetti basato su componenti), alla gestione (Criteri di gruppo e Active Directory®), alla diagnostica e al monitoraggio in generale (Infrastruttura diagnostica Windows), alle funzionalità fondamentali di connessione in rete (la nuova implementazione di firewall e TCP/IP), ai componenti di base del server o ai ruoli del server.

Utilizzo di sistemi multiprocessore

Una delle novità a basso livello del sistema è che Windows Server 2008 contiene solo una versione del kernel progettato per funzionare con i sistemi multiprocessore. In passato in Windows si utilizzava una versione specifica per i processori singoli sui computer con una sola CPU, perché tale versione era in grado di garantire prestazioni leggermente migliori omettendo il codice di sincronizzazione necessario solo negli ambienti multiprocessore. Con il miglioramento dell'hardware, il vantaggio in termini di prestazioni offerto dalle ottimizzazioni è diventato trascurabile e nella maggior parte dei sistemi server odierni sono presenti più processori. L'implementazione di una versione per processori singoli è divenuta quindi inutile.

Nella Figura 1 sono illustrate le varianti del kernel di Windows Server 2008, dove la versione utilizzata in un sistema dipende da se si utilizza la versione di debug (Verificata) o la versione finale del sistema operativo, se l'installazione è a 32 bit o a 64 bit (Itanium, Intel 64 o AMD64) e, in caso di installazione a 32 bit, se il sistema dispone di più di 4 GB di memoria fisica o supporta Protezione esecuzione programmi. Windows Server 2008 è inoltre l'ultimo sistema operativo Windows Server con una versione a 32 bit.

Figure 1 Varianti del kernel di Windows Server 2008

Kernel	32 bit	64 bit
Multiprocessore	Sì	Sì
Multiprocessore verificato	Sì	Sì
Estensione indirizzo fisico PAE multiprocessore	Sì	No
PAE multiprocessore verificato	Sì	No

Con ogni versione di Windows Server si migliorano le prestazioni negli scenari server principali, come lo scambio di file, l'I/O della rete e la gestione della memoria. Inoltre, in Windows Server 2008 sono disponibili molte modifiche e nuove funzionalità che consentono a Windows di sfruttare le nuove architetture hardware, di adattarsi alle reti a latenza elevata e di rimuovere i colli di bottiglia che limitavano le prestazioni nelle versioni precedenti di Windows. In questa sezione vengono esaminati i miglioramenti apportati al gestore della memoria, il sistema di I/O e l'introduzione di un nuovo file system di rete, SMB 2.0.

Gestione della memoria

Esperimento: visualizzazione dell'I/O di file di grandi dimensioni

Per visualizzare le operazioni di I/O di file di grandi dimensioni in un sistema Windows Server 2008, è possibile utilizzare uno strumento di monitoraggio del file system, come TechNet Sysinternals Process Monitor (technet.microsoft.com/sysinternals/bb896645.aspx).

Esistono vari modi per generare I/O di grandi dimensioni. Se su un secondo sistema è in esecuzione Windows Vista Service Pack 1 o Windows Server 2008, è possibile eseguire Process Monitor sul server e monitorare le operazioni di copia dei file del secondo sistema. In genere è possibile generare anche I/O di file di paging voluminosi, eseguendo un programma a utilizzo intensivo della memoria che provochi la scrittura, da parte del gestore della memoria, di pagine nel file di paging.

Nella Figura A è illustrato Process Monitor dopo l'esecuzione di un programma a utilizzo intensivo della memoria su un sistema Windows XP, con l'opzione Enable Advanced Output attivata nel menu delle opzioni di Process Monitor e un filtro impostato per visualizzare soltanto le operazioni di scrittura nel file di paging, pagefile.sys. Nella colonna dei dettagli è indicato che le scritture sono di 64 KB.

Figura A  (Fare clic sull'immagine per ingrandirla)

Quando si eseguono le stesse operazioni su Windows Server 2008, è probabile che si visualizzi qualcosa di simile a quanto illustrato nella Figura B, con la maggior parte delle scritture prossime a 1 MB.

Figura B  (Fare clic sull'immagine per ingrandirla)

Le prestazioni del gestore della memoria sono state migliorate in Windows Server 2008. Ad esempio, vengono eseguite meno operazioni di I/O su disco, ma di maggiori dimensioni rispetto a Windows Server 2003, durante il recupero dei dati dal file di paging oppure durante gli I/O della lettura in avanti sui file mappati. I file di I/O di maggiori dimensioni sono facilitati dalle modifiche apportate al sistema di I/O, che prevedono la rimozione del limite di 64 KB in vigore fin dalla prima versione di Windows NT®.

Inoltre, è importante sottolineare che le letture dei dati per la lettura in avanti (letture speculative) dai file mappati da Gestione cache in Windows Server 2008 sono, in genere, di dimensioni doppie rispetto a Windows Server 2003 e vengono inserite direttamente nell'elenco di standby (la cache del codice e dei dati del sistema). Questo comportamento si verifica in luogo della richiesta alla Gestione cache della mappatura della memoria virtuale e della lettura dei dati nel working set del sistema (la memoria assegnata al sistema dal gestore della memoria), che potrebbe causare l'inutile eliminazione di altro codice o dati in uso dal working set.

Il gestore della memoria esegue operazioni di I/O di maggiori dimensioni anche durante la scrittura dei dati nel file di paging. Se Windows Server 2003 eseguiva spesso operazioni di scrittura anche minori di 64 KB, il gestore della memoria di Windows Server 2008 esegue in genere scritture di 1 MB.

A parte l'ovvio miglioramento delle prestazioni che si ottiene riducendo il numero di scritture nel file di paging, le maggiori dimensioni contribuiscono anche a ridurre la frammentazione all'interno del file di paging. Si riduce di conseguenza anche il numero di letture e di ricerche sul disco necessarie per leggere più pagine, poiché queste risulteranno più spesso adiacenti.

Il gestore della memoria tenta, inoltre, di scrivere in altre pagine modificate che siano prossime a quella in corso di scrittura nello spazio degli indirizzi del processo e sceglie come destinazione l'area del file di paging in cui già risiedono altre pagine adiacenti. In tal modo si riduce al minimo la frammentazione e si migliorano le prestazioni, perché le pagine potenzialmente da scrivere nel file di paging risultano già scritte. Inoltre, si riduce il numero delle letture nel file di paging necessarie per ottenere un intervallo di pagine di processo adiacenti. Per ulteriori informazioni sull'utilizzo delle dimensioni dell''I/O del gestore della memoria , consultare il riquadro "Esperimento: visualizzazione dell'I/O di file di grandi dimensioni".

SMB 2.0

SMB (Server Message Block) protocollo di file system remoto, anche definito Common Internet File System (CIFS), è stato la base del file serving di Windows fin da quando tale funzionalità è stata introdotta in Windows. Negli ultimi anni le limitazioni di progettazione di SMB hanno causato una riduzione delle prestazioni di Windows in termini di file serving e hanno impedito di sfruttare appieno le nuove funzionalità del file system locale. Le dimensioni massime del buffer che possono essere trasmesse in un singolo messaggio, ad esempio, è di circa 60 KB e SMB 1.0 non era in grado di discernere i collegamenti simbolici sul lato client di NTFS che venivano aggiunti in Windows Vista e Windows Server 2008.

In Windows Vista e Windows Server 2008 è disponibile SMB 2.0, un nuovo protocollo di file serving remoto che Windows utilizza quando sia il client che il server lo supportano. Oltre alla corretta elaborazione dei collegamenti simbolici sul lato client e ad altri miglioramenti di NTFS, SMB 2.0 utilizza la suddivisione in batch per ridurre al minimo il numero di messaggi scambiati tra un client e un server. La suddivisione in batch può comportare un aumento della velocità di trasmissione sulle reti a latenza elevata, come le WAN, perché consente di trasmettere più dati allo stesso tempo.

SMB 1.0 inviava l'I/O per un singolo file in modo sequenziale, mentre in SMB 2.0 è implementato il pipelining dell'I/O, che consente di inviare più I/O contemporanei per lo stesso file. Viene inoltre misurata la quantità di memoria del server utilizzata da un client per gli I/O in corso, al fine di determinare la profondità del pipelining.

Grazie alle modifiche apportate al gestore della memoria di I/O di Windows e al sistema di I/O, all'auto tuning della finestra di ricezione TCP/IP e ai miglioramenti del motore di copia dei file, SMB 2.0 rende possibile un aumento significativo della velocità effettiva e la riduzione dei tempi di copia dei file per i trasferimenti di grandi dimensioni. Poiché SMB 2.0 è implementato in entrambi i sistemi operativi, la distribuzione di file server Windows Server 2008 con client Windows Vista consente di utilizzare SMB 2.0 e di ottenere questi vantaggi in termini di prestazioni.

Affidabilità con la riparazione automatica di NTFS

L'affidabilità è un attributo chiave per i server e in Windows Server 2008 sono disponibili alcune funzionalità avanzate che consentono agli amministratori di configurare server che funzionano senza problemi. Alcune di tali funzionalità sono la correzione in linea della coerenza NTFS, una nuova infrastruttura di segnalazione degli errori hardware e le estensioni di Driver Verifier.

Con i dispositivi di archiviazione di più terabyte di oggi, una verifica della coerenza non in linea su un volume può risultare in un'interruzione del servizio di alcune ore. Riconoscendo che molti danneggiamenti del disco sono localizzati in un singolo file o porzione dei metadati, in Windows Server 2008 è implementata una funzionalità di riparazione automatica di NTFS che consente di riparare il danno con il volume in linea.

Quando rileva un danneggiamento, NTFS impedisce l'accesso ai file danneggiati e crea un thread di lavoro di sistema che esegue le correzioni di tipo Chkdsk sulle strutture di dati danneggiate, consentendo l'accesso ai file riparati non appena possibile. L'accesso agli altri file è garantito senza interruzioni durante questa operazione, riducendo al minimo l'interruzione del servizio.

Infrastruttura WHEA

L'infrastruttura WHEA disponibile in Windows Server 2008 promette di semplificare la gestione degli errori hardware e consente di rispondere in modo proattivo agli errori non irreversibili. I server devono spesso rispondere a precise garanzie in termini di tempo di attività, quindi l'individuazione e risoluzione degli errori in tali sistemi è di importanza fondamentale.

Le analisi degli arresti anomali giunte in Microsoft tramite OCA illustra che circa il 10% degli arresti anomali del sistema operativo sono dovuti a un errore hardware, ma l'individuazione della causa principale degli arresti è stata difficile o impossibile, perché in occasione di un arresto anomalo le informazioni sugli errori fornite dall'hardware sono insufficienti. Inoltre, prima di Windows Server 2008, Windows non forniva alcun supporto incorporato per il monitoraggio dell'integrità dei dispositivi né prevedeva funzionalità di ripristino o notifica di errore imminente. Il motivo di fondo è che i dispositivi hardware non utilizzano un formato di errore comune e non forniscono alcun supporto per il software di gestione degli errori.

WHEA costituisce un meccanismo unificato per il rilevamento e la segnalazione dell'origine dell'errore per i dispositivi della piattaforma, compresi processori, memoria, cache e bus come PCI e PCI Express. Il risultato viene ottenuto implementando l'architettura illustrata nella Figura 2, il cui nucleo è un'API del kernel che le origini degli errori chiamano per segnalare gli errori. L'API richiede una formattazione comune per tutti gli errori e registra gli errori utilizzando gli eventi di Analisi eventi per Windows (ETW) (gli errori irreversibili vengono registrati dopo il riavvio).

Figura 2** Infrastruttura di segnalazione degli errori WHEA **(Fare clic sull'immagine per ingrandirla)

ETW è stato introdotto con Windows 2000 e l'uso che WHEA fa di ETW facilita ai produttori di hardware e di software lo sviluppo di applicazioni di gestione della diagnostica dei dispositivi che utilizzano gli eventi di WHEA. Se un evento è abbastanza grave da provocare un arresto anomalo del sistema, WHEA fa in modo che il record dell'arresto anomalo venga memorizzato nel file dei dettagli dell'arresto anomalo, in modo che gli amministratori possano determinare la causa principale dell'arresto anomalo.

Un'altra parte fondamentale di WHEA è Driver errori hardware specifici di piattaforma (PSHED) in %Systemroot%\System32\Pshed.dll. Il kernel si collega a PSHED, che si interfaccia con l'hardware di piattaforma e firmware, agendo essenzialmente da livello di traduzione tra le rispettive notifiche di errore e l'API di segnalazione degli errori di WHEA. Esiste uno PSHED di Microsoft per ciascuna architettura di piattaforma (x86, x64, Itanium) e PSHED espone un modello di plug-in, in modo che i produttori e fornitori di hardware possano sostituire i comportamenti predefiniti con quelli specifici per le proprie piattaforme.

Infine, i componenti del sistema che si interfacciano con le altre origini di errore (tra cui i driver dei dispositivi, l'Hardware Abstraction Layer e il kernel) possono implementare i gestori degli errori hardware a basso livello (LLHEL) che gestiscono inizialmente una condizione di errore. Un compito dei LLHEL consiste nell'estrarre le informazioni sull'errore dal dispositivo, notificare a PSHED che è necessario consentire la raccolta di ulteriori informazioni di errore della piattaforma e chiamare quindi l'API di segnalazione degli errori WHEA del kernel.

Driver Verifier

Driver Verifier, un potente strumento per monitorare i driver dei dispositivi con problemi e l'hardware difettoso, è stato inserito in ogni copia di Windows, fin da Windows 2000. Gli amministratori in genere configurano Driver Verifier (%Systemroot%\System32\Verifier.exe) in modo da controllare attentamente il comportamento dei driver dei dispositivi sospettati di provocare arresti anomali del sistema. Driver Verifier rileva le operazioni non valide dei driver, in modo che un file dei dettagli dell'arresto anomalo punti direttamente alla parte responsabile dell'errore.

Uno svantaggio delle implementazioni di Driver Verifier precedenti era la necessità di riavviare il sistema per la maggior parte delle modifiche di configurazione, un'operazione ovviamente poco indicata per i server di produzione. Con l'implementazione di Driver Verifier di Windows Server 2008 il processo è stato migliorato, eliminando la necessità di riavviare il sistema per le verifiche più utili, in modo da consentire la risoluzione dei problemi di un server senza doverlo riavviare.

Inoltre, con Driver Verifier vengono introdotte tre verifiche nuove, visibili nella Figura 3. Le verifiche di protezione garantiscono che i driver dei dispositivi impostino autorizzazioni protette sugli oggetti utilizzati per interfacciarsi con le applicazioni. La forzatura delle richieste di I/O in sospeso sottopone a test la flessibilità di un driver nelle operazioni di I/O asincrone che vengono completate immediatamente invece che dopo un ritardo. Le altre verifiche varie ricercano i driver che liberano erroneamente delle risorse in uso, utilizzano in modo non corretto le API di registrazione di Strumentazione gestione windows (WMI) e perdono gli handle delle risorse.

Figura 3** Driver Verifier con le opzioni di Windows Server 2008 attivate **(Fare clic sull'immagine per ingrandirla)

Scalabilità

Per scalabilità si intende la capacità di un sistema operativo o di un'applicazione di utilizzare in modo efficace più processori e grandi quantità di memoria. In ogni nuova versione di Windows la scalabilità viene migliorata riducendo al minimo o eliminando l'uso di blocchi che riducono il parallelismo sui multiprocessori e Windows Server 2008 non fa eccezione a questa regola.

Un miglioramento relativamente piccolo, ma significativo, è nel codice che esegue la scadenza del timer, che non acquisisce più il blocco del dispatcher, un blocco della pianificazione in tutto il sistema utilizzato da tutte le operazioni di sincronizzazione a basso livello. La riduzione che ne risulta nell'overhead di sincronizzazione della CPU, consente ai sistemi di terminal server di Windows Server 2008 di supportare circa il 30% in più di utenti contemporanei rispetto a Windows Server 2003.

Le altre novità nella scalabilità di Windows Server 2008 comprendono i miglioramenti della porta di completamento, una nuova implementazione del pool di thread, l'utilizzo più efficiente dell'hardware NUMA (Non-Uniform Memory Access) e il partizionamento dinamico del sistema.

Miglioramento nella gestione della porta di completamento I/O

La maggior parte delle applicazioni server di Windows scalabili, tra cui IIS, SQL Server® ed Exchange Server, si basano su un'API di sincronizzazione di Windows denominata porta di completamento per ridurre al minimo le commutazioni tra più thread di esecuzione durante le operazioni di I/O. A tal fine vengono prima associate le notifiche degli arrivi di nuove richieste, come le connessioni tra client e server sul Web, a una porta di completamento e viene quindi dedicato un pool di thread all'attesa delle notifiche. Quando arriva una richiesta, Windows pianifica un thread, che di solito esegue quindi altre operazioni di I/O, come la lettura di una pagina Web da disco e l'invio della pagina al client per completare la richiesta.

Perché lo stesso thread possa tornare appena possibile ad attendere altre richieste dei client, il thread invia gli I/O in modo asincrono e associa i completamenti di I/O alla porta di completamento. Il thread torna quindi in attesa sulla porta di completamento, che pianificherà il thread non appena arriva una nuova richiesta o viene completato uno degli I/O. In questo modo lo stesso thread resta attivo su una CPU, elaborando le richieste dei client o restando in attesa sulla porta di completamento.

Uno svantaggio dell'implementazione della porta di completamento nelle versioni precedenti di Windows consisteva nel fatto che, al termine di un'operazione di I/O, il sistema di I/O attivava il thread che aveva emesso l'I/O in modo che eseguisse subito una piccola parte dell'elaborazione di completamento, indipendentemente dalle operazioni in corso. Se erano attivi altri thread, capitava spesso che l'utilità di pianificazione annullasse un thread attivo e il contesto venisse commutato all'emittente.

Windows Server 2008 evita queste commutazioni di contesto differendo l'elaborazione del completamento al thread successivo, in attesa della porta di completamento a cui l'I/O è associato. Così, anche se è presente un altro thread in attesa sulla porta di completamento, l'elaborazione del completamento viene eseguito prima dell'altro codice e l'unità di pianificazione non deve commutare al thread emittente. Questa riduzione delle commutazioni di contesto può comportare un netto miglioramento della scalabilità di applicazioni server con grandi carichi di lavoro.

Pool di thread più efficienti

La scrittura di applicazioni in grado di sfruttare i vantaggi offerti dalle CPU multiple può risultare complessa, quindi con Windows XP sono stati introdotti i pool di thread di lavoro, un'infrastruttura con API associata che astrae i dettagli dell'esecuzione di piccole unità di lavoro tra le CPU. Un'applicazione specifica gli elementi di lavoro all'API del pool di thread, che quindi li esegue su uno dei vari thread che crea e gestisce per ciascuna CPU del sistema.

Lo scopo del pool di thread consiste nel ridurre al minimo le commutazioni di contesto, utilizzando gli stessi thread per eseguire più elementi di lavoro in successione. Quando questo non è possibile perché uno dei thread è già occupato nell'esecuzione di altro lavoro, l'elemento di lavoro viene eseguito utilizzando un altro thread su una diversa CPU.

L'implementazione del pool di thread di Windows Server 2008 prevede un migliore utilizzo delle CPU, indirettamente perché si avvantaggia dei miglioramenti apportati alla porta di completamento e direttamente grazie all'ottimizzazione della gestione dei thread, in modo che i thread di lavoro vengano dinamicamente utilizzati quando necessario per gestire un carico di lavoro dell'applicazione. Inoltre, il nucleo dell'infrastruttura è passato alla modalità kernel, riducendo al minimo il numero di chiamate di sistema eseguite dalle applicazioni che utilizzano l'API. Infine, la nuova API semplifica l'esecuzione di determinate operazioni da parte delle applicazioni, come l'interruzione della coda delle unità lavoro durante l'arresto dell'applicazione.

Ottimizzazioni di NUMA

Con Windows Server 2003 sono state introdotte le ottimizzazioni per i dispositivi NUMA nell'utilità di pianificazione dei thread e nel gestore della memoria, ma in Windows Server 2008 sono state aggiunte ottimizzazioni NUMA al gestore dell'I/O e sono state estese le ottimizzazioni NUMA del gestore della memoria.

I sistemi NUMA sono in genere dei sistemi multiprocessore in cui la memoria ha latenze diverse in funzione del processore che vi accede (vedere la Figura 4). La memoria viene divisa in nodi, dove le latenze tra CPU e nodi possono variare e ciascuna CPU è considerata come parte di un nodo a cui ha l'accesso più rapido.

Figura 4** Sistema NUMA di esempio **(Fare clic sull'immagine per ingrandirla)

I sistemi NUMA, soprattutto quelli con più di otto CPU, sono spesso più efficienti in termini di costi e prestazioni dei sistemi ad accesso uniforme alla memoria. Mentre un sistema ad accesso uniforme alla memoria deve rendere la memoria ugualmente disponibile a tutte le CPU, un sistema NUMA può implementare interconnessioni ad alta velocità per la memoria direttamente connessa a una CPU e connessioni a latenza elevata più economiche per CPU e memoria più distanti.

Per scalare in modo efficace su un sistema NUMA, un sistema operativo o un'applicazione deve essere in grado di riconoscere la topologia a nodi, in modo che i calcoli vengano eseguiti vicino alla memoria che contiene i dati e il codice necessari per i calcoli. L'utilità di pianificazione di Windows, ad esempio, assegna a ciascun thread un cosiddetto processore ideale, che corrisponde alla CPU su cui l'utilità di pianificazione tenterà sempre di eseguire il thread. In questo modo diventa più probabile che i dati inseriti dal thread nella cache della CPU restino disponibili per il thread a ogni successiva esecuzione.

In Windows Server 2003 l'utilità di pianificazione espande questo concetto, considerando il nodo che contiene il processore ideale come il nodo ideale del thread e, quando il processore ideale è occupato nell'esecuzione di un altro thread, si tenta di pianificare il thread su un'altra CPU nel nodo ideale. Il gestore della memoria di Windows Server 2003 è quindi diventato compatibile con NUMA e, quando possibile, indirizza le allocazioni di memoria di un thread alla memoria del nodo su cui è in esecuzione il thread.

In Windows Server 2008 il gestore della memoria suddivide i buffer di memoria non di paging del kernel (la memoria utilizzata dal kernel e dai driver dei dispositivi per memorizzare i dati che devono restare nella RAM) tra i nodi, in modo che le allocazioni provengano dalla memoria del nodo in cui ha origine l'allocazione. Le voci della tabella della pagina di sistema (PTE) vengono allocate dal nodo da cui ha origine l'allocazione, se l'allocazione richiede una nuova pagina della tabella delle pagine, invece che da un nodo qualunque, come accade in Windows Server 2003.

In Windows Server 2003 quando un thread eseguiva un'allocazione di memoria, il gestore della memoria preferiva il nodo su cui era in esecuzione il thread al momento dell'allocazione. Se il thread era momentaneamente pianificato su un nodo non ideale, qualsiasi allocazione eseguita durante tale periodo proveniva dal nodo non ideale. Ne conseguiva che, quando veniva alla fine eseguito sul nodo ideale, il thread non risultava vicino come previsto ai dati o al codice memorizzato nella memoria allocata.

Per risolvere questo problema, il gestore della memoria di Windows Server 2008 preferisce il nodo ideale di un thread per tutte le allocazioni del thread, anche quando il thread viene eseguito vicino a un altro nodo. Il gestore della memoria rileva automaticamente le latenze tra processori e nodi, in modo che, se sul nodo ideale non è disponibile memoria, venga controllato il nodo più prossimo al nodo ideale. Inoltre, quando un thread fa riferimento al codice o ai dati, il gestore della memoria esegue la migrazione delle pagine presenti nell'elenco di standby verso un nodo ideale del thread.

Le applicazioni che intendono controllare il posizionamento delle proprie allocazioni possono utilizzare le nuove API di memoria NUMA, che consentono di specificare un nodo preferito per le allocazioni di memoria, le viste del mapping del file e gli oggetti del mapping del file. Per un'allocazione correlata al mapping di un file, il gestore della memoria verifica se l'operazione di mapping specifica un nodo, quindi verifica se l'oggetto del mapping del file ne specifica uno e infine, se non ne è specificato alcuno, ricorre al nodo ideale del thread.

Prima di Windows Server 2008, l'interrupt e la chiamata della procedura differita (DPC) associata per un'archiviazione o l'I/O di rete poteva essere eseguita su qualunque CPU, comprese quelle di un nodo diverso dal nodo di origine dell'I/O, causando potenzialmente la lettura o scrittura dei dati durante l'operazione di I/O nella memoria di un nodo diverso da quello di accesso ai dati.

Per evitare questo problema, il sistema di I/O di Windows Server 2008 indirizza l'esecuzione della DPC a una CPU del nodo che ha avviato l'I/O e i sistemi con dispositivi che supportano il bus PCI MSI-X (un'estensione dello standard MSI) possono ulteriormente localizzare il completamento dell'I/O, utilizzando i driver dei dispositivi che sfruttano le API di Windows Server 2008 per indirizzare un interrupt dell'I/O al processore che l'ha avviato.

Partizionamento dinamico

Uno dei modi per rendere un sistema più scalabile è fare in modo che supporti l'aggiunta dinamica di risorse hardware come CPU e memoria. Questo stesso supporto può anche far aumentare la disponibilità del sistema quando è necessario sostituire tali risorse, poiché non è più necessario riavviare il sistema.

Windows Server 2003 consentiva l'aggiunta di memoria a caldo, in modo che i server che supportavano la memoria dinamica potessero utilizzare la RAM aggiunta dall'amministratore. Windows Server 2008 estende il supporto della memoria dinamica consentendo la sostituzione della memoria.

La RAM che diventa più dipendente dalle correzioni ECC è a rischio di errore o blocco completo, quindi su un server che supporta la sostituzione a caldo, Windows Server 2008 è in grado di eseguire in modo trasparente la migrazione dei dati dai banchi di memoria con errori a quelli sostitutivi. Il risultato si ottiene eseguendo prima la migrazione dei dati che sono sotto il controllo del sistema operativo, arrestando quindi effettivamente i dispositivi hardware in uno stato di alimentazione ridotta, eseguendo la migrazione del resto dei dati della memoria e, infine, rialimentando i dispositivi in modo da riprendere il normale funzionamento.

Windows Server 2008 inoltre supporta l'aggiunta e la sostituzione a caldo dei processori. Per consentire una sostituzione a caldo, l'hardware deve supportare il concetto di CPU di riserva, che può essere sia portata in linea o aggiunta dinamicamente quando una CPU esistente genera indicazioni di errore, una funzionalità attualmente disponibile solo nei sistemi di fascia alta. L'utilità di pianificazione di Windows Server 2008 rallenta l'attività sulla CPU che genera indicazioni di errore ed esegue la migrazione alla CPU sostitutiva. A questo punto è possibile rimuovere la CPU con problemi e sostituirla con una nuova CPU di riserva.

Il supporto di Windows Server 2008 per l'aggiunta di processori a caldo consente a un amministratore di aumentare la potenza di elaborazione del server senza tempi di inattività. Tuttavia, l'utilità di pianificazione e i sistemi di I/O rendono disponibile una nuova CPU solo ai driver dei dispositivi e alle applicazioni che richiedono la notifica di arrivo della CPU tramite le nuove API, perché alcune applicazioni partono dal presupposto che il numero di CPU resta fisso per una sessione di avvio. Un'applicazione può, ad esempio, allocare una serie di code di lavoro che corrispondano a ciascuna CPU, dove un thread utilizza la coda associata alla CPU su cui è in esecuzione. Se l'utilità di pianificazione posizionasse uno dei thread dell'applicazione su una nuova CPU, tenterebbe di fare riferimento a una coda inesistente, danneggiando potenzialmente i dati dell'applicazione e bloccando con ogni probabilità l'applicazione.

Le applicazioni Microsoft basate su server, come SQL Server ed Exchange Server, supportano l'aggiunta di CPU, come molti altri processi core di Windows, tra cui il processo di sistema, il processo di gestione della sessione (%SystemRoot%\System32\Smss.exe) e i processi di hosting dei servizi generici (%Systemroot%\System32\Svchost.exe). Anche i processi di altro tipo possono richiedere la notifica dell'arrivo di una nuova CPU utilizzando un'API di Windows. Quando viene installata una nuova CPU, Windows notifica l'arrivo ai driver dei dispositivi, avvia la CPU e invia infine una notifica ai driver dei dispositivi alle applicazioni scritte in modo da sfruttare le nuove CPU che è possibile, se necessario, allocare delle strutture di dati per controllare l'attività sulla nuova CPU.

Virtualizzazione di computer

Prima di Windows Server 2008, i prodotti di virtualizzazione Microsoft, compreso Virtual Server 2005, venivano implementati utilizzando la virtualizzazione hosted, come illustrato nella Figura 5. Nella virtualizzazione hosted le macchine virtuali vengono implementate da un Monitor macchina virtuale (VMM) che viene eseguito insieme a un sistema operativo host, in genere come un driver di dispositivo. Il VMM sfrutta la gestione delle risorse e i driver di dispositivo del sistema operativo host e, quando il sistema operativo host ne pianifica l'esecuzione, il VMM suddivide il tempo di elaborazione della CPU tra le macchine virtuali attive (VM).

Figura 5** Virtualizzazione hosted **(Fare clic sull'immagine per ingrandirla)

Hyper-V, noto in precedenza con il nome in codice "Viridian", viene implementato utilizzando la virtualizzazione hypervisor. Hypervisor ha il controllo completo di tutte le risorse hardware e anche il sistema operativo Windows Server 2008 che avvia il sistema e tramite il quale si controllano le macchine virtuali essenzialmente viene eseguito in una macchina virtuale, come di vede nella Figura 6.

Figura 6** Architettura di Hyper-V **(Fare clic sull'immagine per ingrandirla)

L'hypervisor può suddividere il sistema in più macchine virtuali e trattare l'istanza di avvio di Windows Server 2008 come partizione principale, o radice, garantendo a tale istanza l'accesso diretto ai dispositivi hardware come dischi, schede di rete e processore grafico. L'hypervisor prevede che la partizione radice esegua le funzioni di risparmio energetico e risponda agli eventi di plug and play dell'hardware. Inoltre l'hypervisor intercetta l'I/O dei dispositivi hardware avviato da una partizione figlio e lo instrada verso la partizione radice, che utilizza i driver dei dispositivi standard di Windows Server 2008 per ottenere l'accesso all'hardware. In questo modo i server che utilizzano Hyper-V possono sfruttare al meglio il supporto di Windows per i dispositivi hardware.

Quando si configura Windows Server 2008 con il ruolo del server Hyper-V, Windows imposta i dati del database di configurazione dell'avvio (BCD) hypervisorimagelaunchtypeboot su auto e configura il driver di dispositivo Hvboot.sys in modo che venga avviato appena possibile nel processo di avvio. Se l'opzione è configurata, Hvboot.sys prepara il sistema alla virtualizzazione, quindi carica %Systemroot%\System32\Hvax64.exe o %Systemroot%\System32\Hvix64.exe in memoria, a seconda che il sistema implementi rispettivamente l'estensione di virtualizzazione AMD-V or Intel VT CPU.

Una volta caricato, l'hypervisor utilizza le estensioni di virtualizzazione per inserirsi sotto Windows Server 2008. Le applicazioni in modalità utente utilizzano il livello di privilegi Ring 3 del processore x64 e il codice in modalità kernel viene eseguito al livello Ring 0, quindi l'hypervisor opera al livello di privilegio concettuale di Ring -1, poiché può controllare l'ambiente di esecuzione del codice eseguito al livello Ring 0.

Quando si utilizza la console di gestione di Hyper-V per creare o inizializzare una partizione figlio, questa comunica con l'hypervisor utilizzando il driver %Systemroot%\System32\Drivers\Winhv.sys, che utilizza l'API di hypercall pubblicamente documentata per ottenere dall'hypervisor la creazione di una nuova partizione con le dimensioni della memoria fisica e le caratteristiche di esecuzione specificate. Il servizio della macchina virtuale (%Systemroot%\System32\Vmms.exe) all'interno della partizione radice è ciò che crea un processo di lavoro della macchina virtuale (%Systemroot%\System32\Vmwp.exe) per ciascuna partizione figlio per gestire lo stato della partizione figlio.

Un modo in cui Windows migliora le prestazioni dei sistemi operativi della macchina virtuale figlio è l'implementazione sia in Windows Server 2008 che in Windows Vista degli enlightenment, che sono sequenze di codice che si attivano solo quando il sistema operativo viene eseguito su un hypervisor che implementa l'API hypercall di Microsoft. Poiché richiede direttamente i servizi dell'hypervisor, la macchina virtuale figlio evita l'overhead del codice di virtualizzazione che risulterebbe se l'hypervisor dovesse indovinare l'intento del sistema operativo figlio.

Un sistema operativo guest, ad esempio, che non implementa gli enlightenment per gli spinlock, che esegue la sincronizzazione multiprocessore a basso livello, resterebbe in un loop stretto in attesa che uno spinlock venga rilasciato da un altro processore virtuale. Una delle CPU hardware ne potrebbe risultare bloccata fina a quando l'hypervisor pianifica il secondo processore virtuale. Sui sistemi operativi con enlightenment il codice spinlock notifica all'hypervisor, tramite hypercall, quando inizia il loop, in modo che l'hypervisor possa pianificare subito un altro processore virtuale e ridurre lo spreco in termini di utilizzo della CPU.

In Windows Server 2008 le prestazioni della macchina virtuale risultano migliori anche grazie all'accelerazione dell'accesso ai dispositivi da parte della macchina virtuale. Questo risultato si ottiene installando una raccolta di componenti, denominati collettivamente "componenti di integrazione della macchina virtuale", nel sistema operativo figlio.

Se si esegue una macchina virtuale senza installare i componenti di integrazione, il sistema operativo figlio configurerà i driver dei dispositivi hardware per i dispositivi emulati che l'hypervisor gli presenta. L'hypervisor deve intervenire quando un driver di dispositivo tenta di raggiungere una risorsa hardware per informare la partizione radice, che esegue l'I/O del dispositivo utilizzando i driver di dispositivo standard di Windows per conto del sistema operativo della macchina virtuale figlio. Poiché una singola operazione di I/O ad alto livello, come una lettura da un disco, può prevedere molti accessi discreti all'hardware, è possibile che si verifichino molte transizioni, denominate intercettazioni, nell'hypervisor e nella partizione radice.

Con Windows Server 2008 si riducono al minimo le intercettazioni grazie a tre componenti: il driver del bus della macchina virtuale (%Systemroot%\System32\Drivers\Vmbus.sys), i client del servizio virtuale (VSC) e i provider del servizio virtuale (VSP). Quando si installano i componenti di integrazione in una macchina virtuale con un sistema operativo supportato, i VSC assumono il ruolo di driver di dispositivo e utilizzano i servizi del driver Vmbus.sys nella macchina virtuale figlio per inviare le richieste di I/O ad alto livello al driver del bus della macchina virtuale nella partizione radice, tramite l'hypercall e i servizi di condivisione della memoria dell'hypervisor. Nella partizione radice Vmbus.sys inoltra la richiesta al VSP corrispondente, che avvia quindi le richieste di I/O Windows standard mediante i driver di dispositivo della partizione radice.

Come si può vedere, Windows Server 2008 ha un ruolo fondamentale nella strategia di virtualizzazione di Microsoft, proprio grazie all'introduzione della virtualizzazione basata sull'hypervisor Hyper-V. Ulteriori informazioni su queste e altre funzionalità verranno pubblicate nella prossima edizione del mio libro, Microsoft Windows Internals, in uscita tra qualche mese.

Mark Russinovichè un Technical Fellow di Microsoft nella Platform and Services Division. È coautore di Microsoft Windows Internals (Microsoft Press, 2004) e spesso partecipa come oratore a conferenze su IT e sviluppo, tra cui Microsoft TechEd e Professional Developers Conference. È entrato in Microsoft dopo l'acquisizione dell'azienda che ha cofondato, Winternals Software. Ha inoltre creato Sysinternals, dove ha pubblicato molte diffuse utilità, tra cui Process Explorer, Filemon e Regmon.

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