Ottobre 2008 Ottobre 2008
Virtualizzazione: Introduzione a Hyper-V in Windows Server 2008
L'introduzione di Hyper-V rende la virtualizzazione una soluzione sempre meno irrinunciabile per gli ambienti IT. In questo articolo viene fornita una panoramica sull'attuale mercato della virtualizzazione e sul modo in cui Hyper-V migliora la facilità di gestione, l'affidabilità e la sicurezza della virtualizzazione Rajiv Arunkundram
Virtualizzazione: Gestisci i tuoi ambienti virtuali con VMM 2008
System Center Virtual Machine Manager fornisce un'interfaccia consolidata per la gestione dell'infrastruttura virtuale. La versione più recente supporta anche Windows Server 2008 Hyper-V e le macchine virtuali di VMware. Esplora le nuove funzionalità e ottieni un resoconto sull'utilizzo di VMM per centralizzare le tue attività di gestione. Edwin Yuen
Virtualizzazione: Introduzione a Microsoft Application Virtualization
Microsoft Application Virtualization (App-V) consente di fornire desktop virtualizzati a sistemi client all'interno delle organizzazioni. Questo semplifica la gestione dei sistemi e permette ai dipendenti di non essere legati ai propri desktop. Scopri in questo articolo come funziona App-V e come è possibile distribuire questa soluzione nella tua organizzazione. Anthony Kinney
Virtualizzazione: Ottenere una disponibilità elevata per Hyper-V
Il consolidamento dei server in un numero minore di macchine offre molti vantaggi, ma è fondamentale pianificare la disponibilità elevata dei sistemi. Ecco una guida sulle modalità di utilizzo del clustering di failover di Windows Server 2008 per assicurare la disponibilità elevata alle macchine virtuali Hyper-V. Steven Ekren
Virtualizzazione: Backup e ripristino di emergenza per la virtualizzazione server
La virtualizzazione apporta modifiche significative al ripristino di emergenza. In questo articolo viene fornita un'introduzione sulle modalità di integrazione della piattaforma di virtualizzazione Microsoft nella pianificazione del ripristino di emergenza nonché un approfondimento delle opzioni di backup e ripristino e alcune considerazioni su Windows Server 2008 Hyper-V. Adam Fazio
Virtualizzazione: Strumenti essenziali per la pianificazione della tua infrastruttura virtuale
La tua infrastruttura è pronta per la virtualizzazione? Microsoft Assessment and Planning Toolkit, uno strumento di valutazione dell'intera infrastruttura, può aiutarti a comprendere meglio la tua infrastruttura IT e stabilire se i sistemi sono pronti all'aggiornamento o alla migrazione verso altre tecnologie, compresa la virtualizzazione. Jay Sauls e Baldwin Ng
Columns
From the Editor: È un mondo virtuale (virtualizzato): | Letters: La parola ai lettori: | Toolbox: Nuovi prodotti per professionisti IT:
SQL Q&A: Log delle transazioni di grandi dimensioni, utilizzo della funzione Repair e molto altro ancora: In questo numero Paul Randal risponde a domande relative all'esecuzione di backup e ripristino, esamina le differenze tra la distribuzione di log e il mirroring del database e spiega i motivi per cui la funzione Repair deve essere utilizzata solo in casi estremi.Paul S. Randal | Utility Spotlight: Strumento di manutenzione delle macchine virtuali non in linea: Le macchine virtuali non in linea non ricevono automaticamente gli aggiornamenti necessari a garantirne sicurezza e conformità. Ciò potrebbe rappresentare un rischio per l'intero ambiente IT. Scopri come lo Strumento gratuito di manutenzione delle macchine virtuali non in linea permette di automatizzare il processo di aggiornamento delle macchine virtuali.Peter Skjøtt Larsen e Suveen Kumar Reddy Vuppala | Windows PowerShell: Potenza dei profili: Chi non ha mai desiderato poter avviare Windows PowerShell con un ambiente di lavoro che risponde alle proprie esigenze? Don Jones spiega come utilizzare i profili per la personalizzazione della shell di Windows PowerShell.Don Jones
Hey, Scripting Guy!: Le ultime parole famose: Gli Scripting Guy parlano di Socrate e riprendono l'argomento dell'esecuzione di query su file XML. Questa volta, però, il file XML è strutturato in modo tale che, anziché utilizzare nodi figlio, i valori della proprietà aggiuntive sono configurati come attributi.Microsoft Scripting Guys | The Desktop Files: Personalizzazione di Servizi di distribuzione Windows: Wes Miller analizza i Servizi di distribuzione Windows, illustrando come sia possibile personalizzarli e configurarli per soddisfare le esigenze della propria organizzazione.Wes Miller | Security Watch: Riesaminiamo insieme le 10 leggi immutabili della sicurezza, Parte 1: Dalla pubblicazione di "Le 10 leggi immutabili della sicurezza" 8 anni fa sono avvenuti innumerevoli cambiamenti. In questo numero Jesper Johansson presenta la prima parte della serie in cui analizza tali leggi da una prospettiva attuale, per valutare se esse siano valide ancora oggi.Jesper M. Johansson
Field Notes: Codice a barre a colori ad alta capacità: Gavin Jancke ha sviluppato un nuovo codice a barre che sfrutta colori e triangoli, con una capacità notevolmente superiore rispetto ai codici a barre tradizionali in bianco e nero. In questo articolo vengono presentati i codici a barre a colori ad alta capacità.Gavin Jancke | Windows Confidential: Lavorare sodo o far lavorare il cervello?: Raymond Chen analizza le relazioni oblique esistenti tra bug ed errori e spiega perché è importante che i programmatori si soffermino sull'analisi dei problemi ma anche che i loro sforzi producano dei risultati.Raymond Chen


Virtualizzazione
Introduzione a Hyper-V in Windows Server 2008
Rajiv Arunkundram
Panoramica:
  • Che cos'è la virtualizzazione?
  • Tre architetture di virtualizzazione
  • Confronto tra Hypervisor microkernelizzato e monolitico
  • Funzionalità di Hyper-V

Indice
Il mercato della virtualizzazione dei server
Funzionamento della virtualizzazione dei server
Tipi di soluzioni di virtualizzazione
Windows Hypervisor
La partizione padre
Architettura di condivisione periferiche
Componenti di integrazione
Set di funzionalità Hyper-V
Scalabilità
Disponibilità elevata
Sicurezza
Facilità di gestione
Conclusioni
Negli ultimi tempi, si è parlato molto di virtualizzazione e soprattutto della virtualizzazione dei server. Si tratta di una delle tendenze più interessanti dell'industria ed è potenzialmente in grado di cambiare, nell'arco di pochi anni, il paradigma delle modalità di distribuzione dei sistemi IT. La virtualizzazione dei server non cambierà solo il modo di progettare i server e l'utilizzo del sistema da parte degli amministratori e degli architetti IT, ma interesserà anche i processi e gli strumenti impiegati nella gestione di un ambiente che diventerà certamente sempre più dinamico.
La virtualizzazione è in realtà disponibile già da diverso tempo, ma la tecnologia continua a svilupparsi. In effetti, la parola stessa ha ancora significati diversi per utenti diversi. In senso ampio, tuttavia, la virtualizzazione è l'astrazione di un livello dello stack tecnologico dal livello successivo, come l'archiviazione dai server o il sistema operativo dalle applicazioni. L'astrazione dei diversi livelli, a sua volta, consente il consolidamento e una migliore gestibilità.
Come concetto, la virtualizzazione si applica all'archiviazione, alle reti, ai server, alle applicazioni e all'accesso. Per quanto riguarda l'archiviazione e le reti, lo scopo della virtualizzazione è quello di aggregare una serie di dispositivi diversi affinché il pool totale delle risorse sembri e si comporti come una sola entità. Ad esempio, è possibile configurare una soluzione di archiviazione da 40 TB anziché una serie di 20 dispositivi di archiviazione da 2 TB. Tuttavia, con altri componenti, la virtualizzazione ha un effetto opposto, contribuendo a fare sembrare un sistema singolo un'insieme di sistemi multipli. L'esempio più comune è la virtualizzazione dei server, in cui si ospitano più istanze e ambienti operativi su un unico server.
Microsoft ha affrontato la virtualizzazione a diversi livelli, dal desktop al datacenter, con soluzioni per la virtualizzazione di server, applicazioni, presentazioni e desktop. Il punto comune a tutte queste soluzioni è la parte di gestione con Microsoft System Center. In questo articolo mi concentrerò sul componente di virtualizzazione dei server e in particolare su come Hyper-V, una delle funzionalità principali di Windows Server 2008, si adatti alla formula per un datacenter dinamico.

Il mercato della virtualizzazione dei server
In primo luogo, è utile prendere in esame l'offerta presente oggi sul mercato nonché la tendenza del mercato globale. A seconda degli studi presi in considerazione, alcuni analisti stimano che il 5–9% di tutti i server fisici attualmente venduti vengono utilizzati come host di virtualizzazione. Questa potrebbe sembrare una percentuale sostanziosa in un mercato in cui ogni anno vengono venduti più di nove milioni di server fisici. Ma una cosa è certa: è ancora presente un'opportunità di mercato enorme con l'aumentare del numero di clienti che familiarizzano con la virtualizzazione e desiderano utilizzarla.
È importante notare gli ambienti in cui viene adottata la virtualizzazione. Sicuramente, i clienti aziendali sono stati i primi ad utilizzare e testare la virtualizzazione. Tuttavia, anche aziende di piccole e medie dimensioni implementano la virtualizzazione. L'impiego della virtualizzazione interessa vari tipi di carichi di lavoro, dalla gestione e applicazioni aziendali al Web e alla posta elettronica.
Quindi perché oggi si parla così tanto di virtualizzazione? Esistono diversi fattori, uno dei quali è rappresentato dal tempo. Alcuni fattori chiave dell'industria sono affiorati allo stesso tempo, contribuendo a favorire un impiego maggiore della virtualizzazione. Tali fattori comprendono il passaggio ai computer a 64 bit, i processori multicore e anche l'interesse per un'informatica sostenibile al fine di migliorare l'utilizzo del sistema.
I sistemi diventano molto più grandi e richiedono una tecnologia come la virtualizzazione per sfruttare appieno la potenza del sistema. Ma se è vero che la tecnologia di base e la legge di Moore presentano una tendenza costante in termini di produzione di una capacità di elaborazione maggiore rispetto a quella utilizzabile dai sistemi, ora siamo anche più consapevoli dell'impatto ambientale, dei requisiti di alimentazione e dei costi di raffreddamento.
Tutti questi fattori, insieme alla semplice motivazione del rendimento dell'investimento (ROI) nell'adozione della virtualizzazione, dovrebbero accelerare l'utilizzo della virtualizzazione nelle imprese di grandi e piccole dimensioni. E noi, professionisti IT, possiamo attenderci che tutti i maggiori attori continueranno a investire in questa tecnologia nei prossimi anni e a migliorarne le caratteristiche e la funzionalità.

Funzionamento della virtualizzazione dei server
La virtualizzazione dei server permette di prendere un dispositivo fisico singolo come punto di partenza e installare (ed eseguire simultaneamente) due o più ambienti operativi che sono potenzialmente diversi e presentano diverse identità, stack di applicazioni, ecc. Hyper-V è una tecnologia di virtualizzazione a 64 bit di ultima generazione basata su Hypervisor che offre funzionalità di piattaforma affidabili e scalabili. Insieme al System Center, offre un'unica serie di strumenti di gestione integrati per le risorse fisiche e virtuali.
Tutto ciò serve a ridurre i costi, migliorare l'utilizzo, ottimizzare l'infrastruttura e consente alle aziende di disporre rapidamente di nuovi server. Per comprendere meglio l'architettura di Hyper-V, diamo prima un'occhiata ai diversi tipi di soluzioni di virtualizzazione.

Tipi di soluzioni di virtualizzazione
Esistono essenzialmente tre architetture generali utilizzate per la virtualizzazione dei server, come mostrato nella Figura 1. Le differenze fondamentali riguardano la relazione tra il livello di virtualizzazione e l'hardware fisico. Per livello di virtualizzazione intendo il livello di software denominato Virtual Machine Monitor (VMM, da non confondere con Virtual Machine Manager). È questo livello che fornisce la capacità di creare istanze multiple isolate che condividono le stesse risorse hardware di base.
Figura 1 Le tre architetture di virtualizzazione (fare clic sull'immagine per ingrandirla)
L'architettura VMM tipo 2 viene esemplificata dalle macchine virtuali Java. Qui lo scopo della virtualizzazione è quello di creare un ambiente di runtime nel quale il processo possa eseguire una serie di istruzioni senza contare sul sistema host. In questo caso, l'isolamento è per i diversi processi e consente a un'applicazione singola di essere eseguita su diversi sistemi operativi senza preoccuparsi delle dipendenze dei sistemi operativi. La virtualizzazione dei server non rientra in questa categoria.
VMM tipo 1 e VMM ibrido sono probabilmente i due approcci utilizzati più frequentemente oggi. VMM ibrido è uno stadio in cui VMM viene eseguito assieme al sistema operativo host e aiuta a creare macchine virtuali. Esempi di VMM ibrido sono Microsoft Virtual Server, Microsoft Virtual PC, VMware Workstation e VMware Player. Si dovrebbe notare che mentre questi tipi di soluzioni sono eccellenti per uno scenario di client in cui si eseguono macchine virtuali solo per determinati periodi di tempo, i VMM comportano un notevole sovraccarico e quindi non sono adatti per carichi di lavoro dispendiosi in termini di risorse.
In un'architettura VMM tipo 1, il livello VMM opera direttamente sull'hardware. Questo è spesso denominato livello Hypervisor. Questa architettura è stata progettata originariamente nel 1960 da IBM per i sistemi di tipo mainframe e di recente è stata messa a disposizione sulle piattaforme x86/x64 con una varietà di soluzioni, compreso Windows Server 2008 Hyper-V.
Sono disponibili soluzioni in cui l'Hypervisor è una parte incorporata del firmware. Questo, tuttavia, rappresenta semplicemente un'opzione di assemblaggio e non modifica di fatto la tecnologia sottostante.
Per quanto riguarda i VMM tipo 1, esistono essenzialmente due modi principali per l'architettura delle soluzioni Hypervisor: microkernelizzato e monolitico. Entrambi questi approcci, come mostrato nella Figura 2, rappresentano veri VMM tipo 1 in cui l'Hypervisor è installato direttamente sull'hardware fisico.
Figura 2 Le due possibilità di architettura delle soluzioni Hypervisor (fare clic sull'immagine per ingrandirla)
L'approccio con Hypervisor monolitico ospita l'Hypervisor/VMM in un livello singolo che comprende anche la maggior parte dei componenti richiesti, come il kernel, i driver di dispositivo e lo stack I/O. Questo è l'approccio utilizzato da soluzioni quali VMware ESX e dai sistemi mainframe tradizionali.
L'approccio con Hypervisor microkernelizzato utilizza un Hypervisor specializzato, molto sottile che esegue soltanto le attività principali di assicurazione dell'isolamento della partizione e della gestione della memoria. Questo livello non comprende lo stack I/O o i driver di dispositivo. Questo è l'approccio utilizzato da Hyper-V. In questa architettura, lo stack di virtualizzazione e i driver di dispositivo specifici dell'hardware sono situati in una partizione specializzata denominata partizione padre.

Windows Hypervisor
Una chiara separazione tra i sistemi operativi multipli è garantita creando memoria, timer, controllori di interruzioni e processori virtuali. I sistemi operativi utilizzano queste risorse virtuali proprio come utilizzerebbero le loro controparti fisiche.
Windows Hypervisor, parte di Hyper-V, esegue le seguenti attività:
  • Crea partizioni logiche.
  • Gestisce la memoria e la programmazione del processore per i sistemi operativi guest.
  • Fornisce meccanismi per virtualizzare input/output e comunicare fra le partizioni.
  • Applica regole di accesso alla memoria.
  • Applica criteri per l'utilizzo della CPU.
  • Presenta un'interfaccia programmatica semplice, nota come hypercall.
Poiché utilizza l'approccio microkernelizzato, Windows Hypervisor è particolarmente piccolo, con dimensioni inferiori a 1 MB. Questo footprint minimo contribuisce a migliorare la sicurezza complessiva del sistema.
Uno dei requisiti per l'esecuzione di Hyper-V è un sistema x64 che disponga delle tecnologie Intel VT o AMD-V. La tecnologia x64 permette l'accesso a uno spazio di indirizzi maggiore e il supporto di sistemi con più memoria, ammettendo così più macchine virtuali su un solo sistema host. Intel VT e AMD-V sono soluzioni di virtualizzazione assistite da hardware che forniscono un livello ultraprivilegiato nell'architettura ad anello che aiuta a tenere l'ambiente di esecuzione dell'Hypervisor separato dal resto del sistema. Inoltre, consentono a Hyper-V di eseguire un sistema operativo guest non modificato senza registrare perdite significative nella prestazione di emulazione.

La partizione padre
Hyper-V consiste in una partizione padre, che è essenzialmente una macchina virtuale che gode di accesso speciale o privilegiato. Questa è la sola macchina virtuale con accesso diretto alle risorse hardware. Tutte le altre macchine virtuali, note come partizioni guest, passano attraverso la partizione padre per l'accesso al dispositivo.
L'esistenza della partizione padre è abbastanza trasparente. Quando si inizia a installare Hyper-V, la prima cosa da fare è installare Windows Server 2008 x64 Edition sul sistema fisico. Quindi, è necessario selezionare Server Manager, attivare il ruolo Hyper-V e riavviare il sistema. Una volta riavviato il sistema, Windows Hypervisor viene prima caricato e poi il resto dello stack viene convertito per essere la partizione padre.
La partizione padre ha la proprietà della tastiera, del mouse, del schermo video e di altre periferiche collegate al server host. Non ha il controllo diretto sui timer e sui controllori di interruzioni utilizzati dall'Hypervisor.
La partizione padre contiene un provider Strumentazione gestione Windows (WMI) per facilitare la gestione di tutti gli aspetti dell'ambiente virtualizzato, come pure uno stack di virtualizzazione che esegue attività relative a hardware per conto delle partizioni figlio. In più, tutti i driver del fornitore di hardware indipendente (IHV) necessari per l'hardware del sistema host sono contenuti nella partizione padre; qualsiasi driver creato per le edizioni x64 di Windows Server 2008 funzionerà nella partizione padre.

Architettura di condivisione periferiche
Uno dei componenti innovativi di Hyper-V è la nuova architettura di condivisione periferiche che supporta periferiche emulate e sintetiche in ogni sistema operativo guest. L'emulazione di dispositivi è piuttosto utile per supportare sistemi operativi precedenti con i driver dei dispositivi progettati per generazioni di hardware precedenti. Ad esempio, Hyper-V comprende un'emulazione della scheda di rete Intel 21140, che era chiamata scheda di rete DEC 21140 quando venivano venduti molti dei sistemi operativi precedenti.
Generalmente, l'emulazione dei dispositivi è lenta, non facilmente estendibile e non ben scalabile. Ma l'emulazione è ancora importante perché consente di eseguire la maggior parte dei sistemi operativi x86 su Hyper-V. Poiché la virtualizzazione si sta trasformando da tecnologia di nicchia principalmente impiegata per il testing e lo sviluppo in una tecnologia essenziale per gli ambienti di produzione, gli utenti richiedono migliori prestazioni per eseguire carichi di lavoro più grandi. Le periferiche emulate non soddisfano più queste richieste crescenti.
Una soluzione alternativa è l'utilizzo di periferiche sintetiche Hyper-V. Le periferiche sintetiche sono dispositivi virtuali direttamente mappati come dispositivi fisici. A differenza delle periferiche emulate, le periferiche sintetiche non emulano l'hardware legacy. Con il modello di condivisione dell'hardware Hyper-V, i sistemi operativi guest supportati possono interagire direttamente con le periferiche sintetiche che possono non avere controparti fisiche. Questi sistemi operativi utilizzano i client del servizio virtuale (VSC), che funzionano come driver dei dispositivi all'interno del sistema operativo guest.
Invece di accedere all'hardware fisico direttamente, i VSC utilizzano il VMBus, che è un bus in memoria ad alta velocità, per accedere ai provider del servizio virtuale (VSP) nella partizione padre. I VSP della partizione padre quindi gestiscono l'accesso all'hardware fisico sottostante, come mostrato nella Figura 3. Un vantaggio chiave delle periferiche sintetiche è che le prestazioni delle periferiche sintetiche sul VMBus sono più vicine alle prestazioni delle periferiche hardware non virtualizzate.
Figura 3 I VSC utilizzano il VMBus per accedere ai VSP, che quindi gestiscono l'accesso all'hardware fisico sottostante (fare clic sull'immagine per ingrandirla)

Componenti di integrazione
Hyper-V è stato realizzato per fornire chiari limiti tra le varie istanze in esecuzione su un computer. Per attivare l'interazione tra il sistema operativo guest e il sistema operativo host e per fornire alcune funzionalità aggiuntive per i sistemi operativi guest supportati, Hyper-V fornisce componenti di integrazione.
I componenti di integrazione di Hyper-V supportano le funzionalità seguenti:
  • sincronizzazione dell'ora
  • Servizio Copia Shadow del volume (VSS)
  • Funzionalità Heartbeat
  • Arresto guest
  • Scambio coppia di valori chiave (utilizzato per accedere al Registro di un sistema operativo guest)
  • Identificazione sistema operativo
Set di funzionalità Hyper-V
È ovvio che più la piattaforma di virtualizzazione agisce come server fisico, più è facile per le organizzazioni implementare e fare affidamento su carichi di lavoro virtuali. A mio parere, esistono quattro aree principali in cui è possibile suddividere le diverse funzionalità della piattaforma di virtualizzazione.
Oggi la maggior parte delle soluzioni di virtualizzazione basate su hypervisor sono piuttosto simili in termini di caratteristiche e di funzionalità. Nel prossimo futuro, temi come il costo totale di proprietà (TCO) e la facilità di utilizzo costituiranno i principali fattori di differenziazione. Le soluzioni di gestione saranno oggetto di investimenti continui e di sviluppo al fine di rendere più concreta la visione di un ambiente IT dinamico, in cui l'infrastruttura è sufficientemente flessibile per adattarsi alle esigenze aziendali e i modelli e i criteri aiutano a sviluppare un'automazione e una gestione potenziate.

Scalabilità
Utilizzando l'architettura con Hypervisor microkernelizzato, Hyper-V presenta un carico CPU molto basso, lasciando tutto lo spazio necessario per i carichi di lavoro virtualizzati. Permettendo alle macchine virtuali di sfruttare funzionalità e hardware potenti, come la tecnologia multicore, un migliore accesso al disco e una memoria maggiore, Hyper-V migliora la scalabilità e le prestazioni della piattaforma di virtualizzazione.
In combinazione con le altre funzionalità di Windows Server 2008, Hyper-V consente di consolidare la maggior parte dei carichi di lavoro, compresi i carichi di lavoro a 32 e a 64 bit, su un sistema singolo. Inoltre, può favorire ad armonizzare l'utilizzo della tecnologia a 64 bit con un supporto continuo per carichi di lavoro a 32 bit già in uso in tutto l'ambiente.
Il fatto che Hyper-V richieda un sistema host a 64 bit con virtualizzazione assistita da hardware contribuisce ad assicurare l'accesso del sistema host a un grande pool di risorse di memoria. Hyper-V può supportare fino a 1 TB di memoria sull'host, con fino a 64 GB di memoria per macchina virtuale. Questo è fondamentale per coloro che intendono virtualizzare carichi di lavoro che richiedono un impiego intensivo di memoria come Exchange Server e SQL Server.
Inoltre, Hyper-V supporta fino a 16 processori logici sul sistema host, caratteristica che rende Hyper-V scalabile alla maggior parte dei sistemi commodity a 2 e a 4 socket con core multipli. Inoltre è possibile creare una macchina virtuale con fino a quattro processori virtuali per supportare carichi di lavoro che richiedono o sfruttano funzionalità multiprocessore.
Il consolidamento dei server attraverso Hyper-V permette anche ai server di utilizzare un supporto di rete stabile, comprendente VLAN, NAT (Network Address Translation) e criteri di Protezione accesso alla rete (NAP) (quarantena). Essendo una funzionalità di Windows Server 2008, Hyper-V funziona correttamente con altre funzionalità di Windows Server, come BitLocker e Windows PowerShell.

Disponibilità elevata
La disponibilità elevata è uno scenario in cui Hyper-V e le funzionalità di clustering dell'host lavorano insieme per garantire la continuità aziendale e rispondere alle esigenze di ripristino di emergenza. La continuità aziendale è la capacità di minimizzare i tempi di inattività programmati e non programmati. Questi comprendono il tempo perso per funzioni di routine, come la manutenzione e il backup, ma anche le interruzioni di corrente impreviste.
Il ripristino di emergenza è un componente importante della continuità aziendale. I disastri naturali, gli attacchi intenzionali e perfino semplici problemi di configurazione come conflitti di software possono bloccare i servizi e le applicazioni finché gli amministratori non risolvono i problemi e ripristinano i dati. Una strategia aziendale di ripristino di emergenza affidabile deve offrire una perdita di dati minima e funzionalità di gestione remota potenti.
Per quanto riguarda la disponibilità elevata, si dovrebbero considerare tre categorie diverse: tempi di inattività programmati, tempi di inattività non programmati e backup. La protezione per i tempi di inattività programmati è generalmente necessaria per rimuovere le macchine virtuali dal sistema host e poter così eseguire la manutenzione di hardware o applicare patch al sistema host o alla piattaforma di virtualizzazione (che potrebbe richiedere un riavvio).
La maggior parte delle organizzazioni ha finestre di manutenzione programmate e ciò che si cerca di fare in questo caso è di fatto minimizzare o eliminare il periodo in cui le macchine virtuali non saranno disponibili mentre il sistema host è inattivo per la manutenzione. Con la funzionalità Quick Migration è possibile trasferire rapidamente una macchina virtuale in esecuzione da un nodo fisico a un altro in pochi secondi. Così è possibile tenere a disposizione le macchine virtuali per l'uso di produzione mentre si esegue la manutenzione sull'host originale. Una volta terminata la manutenzione, è quindi possibile utilizzare Quick Migration per riportare le macchine virtuali al sistema host originale.
I tempi di inattività non programmati sono tempi di inattività non previsti. Può trattarsi di una catastrofe naturale o della rimozione involontaria di un cavo di alimentazione che provocano l'arresto del server. Sebbene possa sembrare improbabile, nel corso degli anni ho incontrato diversi amministratori a Tech•Ed, VMworld e altre conferenze che conoscono fin troppo bene il caso in cui un server viene spento accidentalmente proprio da un collega.
Con Hyper-V, è possibile creare un cluster host per diversi sistemi host e configurare tutte le macchine virtuali come risorse cluster che possono quindi passare a un altro sistema in caso di guasto di uno degli host. Allo stesso tempo la funzionalità di clustering multisito di Windows Server 2008 consentirà di creare un cluster distribuito geograficamente in modo che, se il datacenter primario non è più disponibile, sia possibile ripristinare le diverse macchine virtuali in un datacenter remoto.
Questa funzionalità è utile anche per proteggere tutte le filiali. Uno dei vantaggi del supporto Hyper-V per i tempi di inattività non programmati è l'indipendenza dal sistema operativo guest, ovvero la possibilità di estendere i suoi benefici di disponibilità elevata a macchine virtuali Linux e versioni precedenti di Windows Server per proteggere e ripristinare i sistemi in modo analogo.
Per quanto riguarda i tempi di inattività non programmati, è importante notare che il ripristino equivale all'arresto e al riavvio del sistema, ciò significa che tutte le informazioni di stato vanno perse. Questo potrebbe rappresentare un problema a seconda del carico di lavoro in esecuzione nella macchina virtuale. Per questo motivo è importante considerare il backup nel contesto della disponibilità elevata.
Hyper-V permette di effettuare il backup di ogni macchina virtuale o di utilizzare il servizio VSS per eseguire backup coerenti di tutte le macchine virtuali con supporto VSS mentre sono ancora in funzione. Con VSS, è possibile configurare l'esecuzione di backup a intervalli stabiliti senza impatto sulla disponibilità del carico di lavoro di produzione assicurando un piano di backup continuo per ripristinare facilmente lo stato nel caso di tempi di inattività non programmati. Per ulteriori informazioni sulle soluzioni di disponibilità elevata con Hyper-V, vedere l'articolo di Steven Ekren "Ottenere una disponibilità elevata per Hyper-V" in questo numero di TechNet Magazine (technet.microsoft.com/magazine/cc837977).

L'architettura di Hypervisor microkernelizzato è progettata per minimizzare la superficie di attacco e migliorare la sicurezza, soprattutto quando Hyper-V è implementato come ruolo di Server Core. Server Core è un'opzione di installazione di Windows Server 2008. L'Hypervisor non contiene nessun driver dei dispositivi o codice di terzi e favorisce così una base più stabile, agile e sicura per l'esecuzione di macchine virtuali. Hyper-V fornisce inoltre una robusta protezione basata sul ruolo con l'integrazione di Active Directory. Hyper-V consente alle macchine virtuali di sfruttare le funzionalità di protezione a livello di hardware, come il bit di disattivazione dell'esecuzione (NX), contribuendo ulteriormente ad aumentare la protezione delle macchine virtuali.
Hyper-V è stato sviluppato con Security Development Lifecycle, come tutti gli altri componenti di Windows Server; sono state inoltre eseguite una modellazione e un'analisi estese delle minacce renderwe Hyper-V una piattaforma di virtualizzazione estremamente protetta. Nell'implementazione di Hyper-V è necessario assicurarsi di seguire le procedure consigliate per l'implementazione di Windows Server 2008 e le procedure consigliate per Hyper-V. Le soluzioni Active Directory, antivirus e antimalware devono essere comprese nel processo. Inoltre, è necessario utilizzare le funzionalità di amministrazione delegata per assicurarsi di utilizzare correttamente i privilegi di accesso di amministratore per gli host di Hyper-V.

Facilità di gestione
È facile passare da un piccolo problema di espansione del server ad un'espansione incontrollata della macchina virtuale. Questo è un rischio dovuto alla semplicità di implementazione delle macchine virtuali. E con la crescente mobilità delle macchine virtuali, si ha anche la responsabilità di sapere esattamente dove vengono eseguite le diverse macchine virtuali, seguire i contesti di protezione, ecc.
Fortunatamente, con Hyper-V non è necessario creare un'infrastruttura di gestione separata per l'ambiente virtuale. Infatti, è possibile integrarlo con gli strumenti di gestione Microsoft, con System Center Virtual Machine Manager e Microsoft System Center Operations Manager, come pure con strumenti di gestione di terzi. Questo permette di gestire le risorse fisiche e virtuali da un'unica console. Per dettagli su System Center Virtual Machine Manager 2008, vedere l'articolo di Edwin Yuen "Gestisci i tuoi ambienti virtuali con VMM 2008" in questo numero di TechNet Magazine (technet.microsoft.com/magazine/cc836456). Allo stesso tempo il supporto di Windows PowerShell facilita l'automazione della attività.
Hyper-V fornisce anche alle macchine virtuali una capacità senza precedenti di utilizzare l'hardware disponibile. Poiché tutti i driver certificati dai laboratori WHQL (Windows Hardware Quality Lab) possono funzionare nella partizione padre, Hyper-V fornisce ampia compatibilità per i driver e le periferiche, rendendo più facile la gestione di driver diversi in esecuzione nell'ambiente.

Conclusioni
Come si è detto in precedenza, la gestione sarà un'area chiave dello sviluppo e della differenziazione. Si assisterà certamente ad una notevole attività in questo settore negli anni a venire. In generale, questo periodo è davvero interessante poiché, con la sua diffusione, la virtualizzazione sta assumendo un ruolo sempre più importante. Per provare Hyper-V o semplicemente per saperne di più, è possibile consultare microsoft. com/Hyper-V.
Rajiv Arunkundram è un Senior Product Manager presso Microsoft e si occupa della virtualizzazione dei server nella divisione Windows Server Marketing. La principale responsabilità di Rajiv è collaborare con clienti e partner per aiutarli a comprendere la strategia e le soluzioni di virtualizzazione di Microsoft da una prospettiva tecnica ed aziendale.


Virtualizzazione
Gestisci i tuoi ambienti virtuali con VMM 2008
Edwin Yuen

Questo articolo si basa su una versione non definitiva di Virtual Machine Manager 2008. Tutte le informazioni riportate sono soggette a modifica.
Panoramica:
  • Supporto per macchine virtuali VMware
  • Automazione e script basati su Windows PowerShell
  • Gestione centralizzata, consolidata
  • Procedure di installazione

Indice
Introduzione a Virtual Machine Manager 2008
Integrazione con System Center
Installazione di Virtual Machine Manager 2008
Aggiunta di host VMware ESX
Migrazione di VMotion
Conclusione
L'anno scorso Microsoft ha introdotto System Center Virtual Machine Manager 2007, il quale fornisce un'interfaccia consolidata per gestire un'infrastruttura virtuale mediante l'esecuzione di Microsoft Virtual Server 2005. Ora, in coincidenza con la presentazione della nuova versione dell'hypervisor di Windows Server 2008 Hyper-V, è stata rilasciata una nuova versione di Virtual Machine Manager (VMM). System Center Virtual Machine Manager 2008 gestisce le installazioni di Microsoft Virtual Server 2005 e di Windows Server 2008 Hyper-V ma il supporto è stato esteso anche ai server di VMware Infrastructure 3 (ESX/ESXi). Con VMM, si dispone di un'interfaccia di gestione integrata che funziona con l'intera infrastruttura virtuale, compresi i sistemi di Microsoft e VMware.
VMM supporta tutte le attività di virtualizzazione tradizionali, tra cui le distribuzioni rapide delle macchine virtuali (VM) dai modelli e dalle macchine virtuali preconfigurate, le conversioni da macchina fisica a virtuale (P2V), una libreria centralizzata di oggetti dell'infrastruttura virtuale oltre alla conversione da macchina virtuale a macchina virtuale (V2V) di macchine virtuali VMware (file di configurazione VMX e dischi virtuali VMDK) a macchine virtuali Hyper-V. Inoltre, l'integrazione di VMM con gli altri componenti della famiglia System Center riduce la gestione dei sistemi fisici e virtuali a un singolo riquadro.
In quest'articolo prenderò in esame VMM 2008 e le nuove funzionalità previste per agli amministratori IT. Indicherò quindi i requisiti e le operazioni necessarie per un'installazione VMM. Infine, esaminerò in dettaglio le modalità di utilizzo di alcune delle nuove funzionalità di VMM 2008.

Introduzione a Virtual Machine Manager 2008
System Center Virtual Machine Manager 2008 è un'applicazione autonoma che fornisce una gestione centralizzata a livello aziendale delle macchine virtuali in esecuzione in Microsoft Virtual Server 2005 R2 SP1, Windows Server 2008 Hyper-V, Microsoft Hyper-V Server 2008 e server VMware Infrastructure 3 (ESX/ESXi). Insieme ad altri prodotti System Center, VMM fornisce una gestione dell'infrastruttura fisica e virtuale end-to-end. Figura 1 mostra il layout dell'architettura di Virtual Machine Manager.
Figura 1 Architettura di System Center Virtual Machine Manager 2008 (fare clic sull'immagine per ingrandirla)
Come noteranno coloro che hanno familiarità con VMM 2007, in VMM 2008 sono presenti molte più interfacce per il sistema VMM (vedere la Figura 1). Le caselle in alto a sinistra rappresentano VMM 2008; le caselle in alto a destra rappresentano System Center Operations Manager 2007 e nella parte inferiore sono indicati i sistemi gestiti e le interfacce. Le caselle rosse indicano i server di gestione, le caselle blu mostrano gli input del sistema e le caselle verdi sono i sistemi host gestiti con gli oggetti gestiti evidenziati in giallo.
La casella rossa in alto a sinistra rappresenta il servizio server di Virtual Machine Manager 2008. Nella parte superiore sono indicate le diverse interfacce nel servizio; la Console amministrazione, l'interfaccia Windows PowerShell e il Portale web self-service con accesso utente delegato. Windows PowerShell costituisce la base per tutti gli accessi al server VMM. La Console di amministrazione VMM è costruita interamente sulla base di Windows PowerShell, pertanto è possibile creare in maniera semplice gli script di Windows PowerShell eseguiti dal servizio server VMM. Quindi l'API pubblica per VMM 2008 è Windows PowerShell e qualsiasi programma che possa avvalersi di VMM tramite Windows PowerShell. Un ottimo esempio è l'integrazione di XenDesktop Desktop Delivery Controller di Citrix con Virtual Machine Manager, progettato interamente mediante Windows PowerShell.
Il supporto per VMM è un database SQL Server 2005 o SQL Server 2008, un'installazione completa o SQL Server Express Edition se non è disponibile nessun altro database. Il diagramma mostra che Operations Manager e Virtual Machine Manager fanno entrambi riferimento a SQL Server, ciò nonostante i due programmi non condividono un database. Entrambi funzionano sulla stessa versione di SQL Server. L'effettiva integrazione tra Virtual Machine Manager e Operations Manager avviene grazie a un connettore disponibile attraverso VMM. Questo connettore consente a VMM e OpsMgr di condividere i dati spostando le informazioni di virtualizzazione in OpsMgr e trasferendo i dati OpsMgr a VMM per l'esecuzione di azioni.
La parte inferiore del diagramma mostra gli host gestiti. VMM 2008 gestisce ancora gli host della macchina virtuale Virtual Server 2005 R2 SP1 e la condivisione di una libreria centralizzata, come in VMM 2007. Va notato che in VMM la condivisione della libreria non è un archivio speciale di file né un server. È semplicemente una condivisione di file Windows gestita da VMM. È possibile gestire la libreria attraverso VMM o copiare e cancellare con facilità i file dalla condivisione file e consentire a VMM di individuare le modifiche. Inoltre, è possibile disporre di librerie multiple, un'opzione utile per i gruppi di server delegati e per i server in uffici remoti.
Una novità di VMM 2008 è la capacità di gestire gli hypervisor Hyper-V e ESX. La gestione di host Hyper-V viene realizzata attraverso la Gestione remota Windows (WinRM) e l'Interfaccia di Strumentazione gestione Windows (WMI). Infatti, quando viene aggiunto un potenziale host Hyper-V, se in Windows Server 2008 non è attivato il ruolo Hyper-V, VMM può attivare automaticamente questo ruolo per l'amministratore. Questa funzionalità è disponibile anche per host Virtual Server potenziali per i sistemi Windows Server 2003.
La gestione degli host VMware VI3 ESX avviene in realtà attraverso un server VirtualCenter di VMware. VMM 2008 si interfaccia con VirtualCenter attraverso l'API basata sui servizi Web di VirtualCenter. Pertanto, per la gestione di VMware è necessario un server VirtualCenter e la maggior parte delle installazioni aziendali di VMware disporrà almeno di un server VirtualCenter. La caratteristica peculiare di VMM 2008 è la capacità di gestire server multipli VirtualCenter. VMM è in grado di aggiungere server multipli VirtualCenter, consentendo a un amministratore di aggregare l'intera infrastruttura VMware, e fornisce una panoramica unica dell'azienda, cosa che prima non era possibile.
Facendo parte della famiglia di prodotti System Center, VMM utilizza l'interfaccia di System Center o Outlook nella Console di amministrazione. La Console di amministrazione VMM non è uno snap-in MMC; è un'applicazione completamente nuova creata utilizzando Microsoft .NET Framework e progettata su Windows PowerShell 1.0. Infatti, come sottolineato in precedenza, qualsiasi azione nella Console di amministrazione richiama il comando di Windows PowerShell associato. In questo modo è l'interfaccia utente ad utilizzare concretamente Windows PowerShell. Qualsiasi comando o funzione eseguiti nella Console di amministrazione possono essere realizzati attraverso la riga di comando in Windows PowerShell.
Ogni procedura guidata nella Console di amministrazione presenta inoltre un pulsante Visualizza script che mostra lo script Windows PowerShell associato per il comando da eseguire - un valido punto di partenza per scoprire le modalità di relazione di Windows PowerShell con VMM. Una novità in VMM 2008, l'azione Visualizza script apre gli script in Blocco Note affinché possano essere modificati con facilità direttamente da VMM. Inoltre, è possibile salvare gli script modificati per poi riutilizzarli direttamente dalla libreria di VMM—un'altra novità di VMM 2008. I cmdlet di VMM 2007 sono stati aggiornati per VMM 2008, offrendo supporto per i server di VMware. I cmdlet stessi funzionano attraverso le piattaforme di virtualizzazione in modo tale che i cmdlet, tra cui New-VM, siano in grado di funzionare su entrambi i sistemi Microsoft e VMware. Pertanto gli amministratori IT possono utilizzare un gruppo di cmdlet per gestire gli host di Virtual Server, Hyper-V e VMware ESX.
Virtual Machine Manager 2008 è stato progettato per offrire tre fondamentali vantaggi agli amministratori IT:
  • Ottimizzare l'utilizzo delle risorse
  • Acquisire maggiore flessibilità
  • Utilizzare al meglio le competenze esistenti
Questi vantaggi sono favoriti da numerose funzionalità. In primo luogo, VMM aiuta a ottimizzare l'utilizzo delle risorse integrando la gestione dell'intera infrastruttura virtuale, a prescindere dall'hypervisor. Grazie all'integrazione dei sistemi Microsoft e VMware, VMM 2008 fornisce una panoramica unica di tutti gli host e le macchine virtuali, come mostrato nella Figura 2, e consente agli amministratori di filtrare e visualizzare i propri sistemi secondo parametri quali l'host, il sistema operativo, il proprietario, la data aggiunta, ecc.
Figura 2 La Console di VMM mostra la gestione integrata di Microsoft e VMware (fare clic sull'immagine per ingrandirla)
VMM aiuta inoltre a ottimizzare l'utilizzo delle risorse del sistema attraverso un semplice consolidamento del server con conversioni P2V e V2V. P2V offre la possibilità di consolidare le macchine fisiche esistenti in macchine virtuali senza doverle reinstallare. Ciò è utile soprattutto per la conversione di macchine il cui hardware è sfruttato in maniera limitata in modo da ottimizzare le risorse raggruppando diverse macchine a basso utilizzo in un unico hardware fisico. P2V è una funzionalità integrata di VMM e non richiede software o server aggiuntivi. In VMM 2008 è supportato un numero maggiore di sistemi fisici, tra cui Windows Vista, Windows Server 2008 e gli host x64. La funzionalità P2V di VMM è di grande supporto per gli strumenti di pianificazione quali Microsoft Assessment and Planning (MAP) (di cui tratta l'articolo di Baldwin Ng e Jay Sauls in questo numero di TechNet Magazine), che aiuta a identificare i candidati per il consolidamento del server.
Se si dispone già di macchine virtuali nel formato VMDK di VMware, VMM consente di utilizzare V2V per convertire i VMDK esistenti nel formato VHD. Questo processo avviene non in linea — la macchina virtuale di VMware deve essere arrestata mentre il processo V2V converte il file VMDK effettivo in VHD. È anche possibile convertire una macchina virtuale VMware in esecuzione utilizzando la funzione P2V. Questo potrebbe creare un po' di confusione, ma è importante ricordare che le macchine virtuali sono dapprima macchine, quindi virtuali. Tutti gli altri sistemi considerano le macchine virtuali come macchine in esecuzione, così come avviene per la funzionalità P2V di VMM, che permette di convertire una macchina virtuale in esecuzione in un VHD Microsoft su qualsiasi software di virtualizzazione.
VMM offre agli amministratori IT una maggiore agilità grazie a diverse funzionalità. Una delle funzionalità principali attivate da VMM è la migrazione di macchine virtuali da un host a un altro, aiutando così a mantenere disponibilità elevata e ottimizzazione del server. Con gli host Hyper-V, VMM 2008 supporta Quick Migration, in grado di spostare una macchina virtuale tra host Hyper-V in pochi secondi di inattività. Questo processo richiede un cluster di Windows Server 2008 e l'archiviazione condivisa, ma VMM facilita la gestione e la configurazione.
Con un host ESX di VMware, VMM 2008 supporta anche VMware VMotion, la funzionalità di VMware che sposta le macchine virtuali senza che l'utente percepisca tempi di inattività. A tal fine sono necessari host ESX di VMware con VMotion attivo, poiché è un cluster back-end SAN come Quick Migration. Più avanti nell'articolo, presenterò un VMotion utilizzando VMM 2008.
Infine, VMM 2008 è in grado di eseguire la migrazione di una macchina virtuale esistente di Virtual Server 2005 su un host Hyper-V, eseguendo automaticamente tutti gli aggiornamenti e le conversioni necessarie per la migrazione.
Come parte della distribuzione di qualsiasi macchina virtuale (comprese le migrazioni descritte sopra) avviata attraverso conversioni o nuove distribuzioni, VMM utilizza un processo denominato Posizionamento intelligente per la distribuzione delle macchine virtuali agli host. Il Posizionamento intelligente viene utilizzato anche per eseguire una query su tutti gli host della macchina virtuale in gestione, recupera diversi parametri sulla disponibilità di risorse degli host e restituisce quindi un lungo elenco di host consigliati per la distribuzione della macchina virtuale. Come si può vedere nella Figura 3, il Posizionamento intelligente supporta gli host di Microsoft e VMware assieme alle loro configurazioni di archiviazione. Il Posizionamento intelligente in VMM 2008 è abilitato per piattaforme e per configurazioni. In tal modo raccomanderà solamente: host adatti alla piattaforma host corretta, host raggruppati in cluster se è richiesta disponibilità elevata e host in grado di supportare x64 per VM da x64.
Figura 3 Il Posizionamento intelligente analizza tutti gli host disponibili (fare clic sull'immagine per ingrandirla)

Integrazione con System Center
Una delle funzionalità principali di VMM 2008 è l'integrazione con System Center Operations Manager 2007. Mentre VMM 2007 presenta alcune integrazioni con Operations Manager, VMM 2008 contiene un connettore per Operations Manager che aumenta notevolmente la funzionalità dell'integrazione. Attraverso l'integrazione con Operations Manager, VMM fornisce report consolidati di Operations Manager dalla console di amministrazione, nonché attraverso una nuova funzionalità denominata Performance and Resource Optimization (PRO).
PRO consente a VMM 2008 di creare avvisi denominati Suggerimenti PRO e rimediare ad azioni automatiche sulla base di parametri di monitoraggio di Operations Manager. La Figura 4 mostra alcuni esempi di Suggerimenti PRO. Quando si utilizza un management pack con PRO attivato (PRO pack), VMM 2008 può eseguire azioni automatiche quali migrazioni di macchine virtuali e creazione di nuove macchine virtuali rifacendosi a parametri basati su host, hypervisor, hardware e carico di lavoro.
Figura 4 I Suggerimenti PRO forniscono avvisi e rimedi relativi ai problemi presenti nell'infrastruttura virtuale (fare clic sull'immagine per ingrandirla)

Installazione di Virtual Machine Manager 2008
Per eseguire l'installazione di System Center VMM 2008 esistono diversi prerequisiti e nuovi requisiti del sistema. Innanzitutto, il server di VMM 2008 richiede Windows Server 2008 x64. Il server non effettua l'installazione su Windows Server 2003 o su versioni x86 di Windows Server 2008. La Console di amministrazione e gli altri componenti possono essere ancora installati su Windows Server 2003 e su Windows XP o su Windows Vista (nel caso della console), con gli stessi requisiti e le stesse procedure di installazione di VMM 2007.
In secondo luogo, VMM 2008 richiede un'installazione su un dominio Active Directory per il modello di protezione. VMM 2008 supporta la gestione degli host della rete perimetrale (non di dominio unito), compreso il P2V di sistemi non di dominio, nuova caratteristica di VMM 2008. Uno dei vantaggi derivanti dall'utilizzo di Windows Server 2008 come piattaforma di installazione è rappresentato dal fatto che molti dei prerequisiti per VMM (quali .NET Framework 3.0, WinRM e Windows PowerShell 1.0) sono già incorporati. Infine, VMM 2008 richiede Windows Automated Installation Kit (WAIK) 3.0 sebbene il programma di installazione di VMM 2008 contenga i file di installazione.
In un ambiente di produzione si consiglia di installare ogni componente VMM su un server di produzione separato, in questa sede descriverò un'installazione su server singolo. L'hardware consigliato per un'installazione del server VMM è un server x64 con velocità di esecuzione pari a 2,8 GHz o superiore e con almeno 2 GB di RAM. Dato che si tratta di un'installazione su server singolo con un database SQL locale, sono necessari 7 GB di spazio su disco rigido. Notare che nel caso in cui si utilizzi un database remoto, è necessario solo 1 GB per l'installazione di VMM. Si consiglia di liberare altri 80 GB di spazio su disco per l'installazione della libreria locale.
Come menzionato in precedenza, VMM viene eseguito su un'installazione di Windows Server 2008 x64. I requisiti di software aggiuntivi comprendono .NET Framework 3.0, Windows PowerShell 1.0, WinRM e IIS 6.0 o versione successiva per il portale self-service. È richiesto anche Microsoft MSXML 6.0 Parser ma è inclusa una parte di .NET Framework 3.0.
Quando si avvia l'installazione di VMM, vengono proposte cinque opzioni: server Virtual Machine Manager, Console di amministrazione, Portale self-service e Agente Locale, così come un'opzione per configurare il Management Pack di Microsoft Operations Manager. Come già accennato, installeremo tutti i componenti su una singola macchina, iniziando dal Server VMM. Una volta avviata l'installazione, le prime schermate controllano i prerequisiti del sistema.
Oltre ai requisiti menzionati in precedenza, la macchina deve disporre di un dominio. L'installazione del server VMM attiva automaticamente le funzioni incorporate eliminando così la necessità di attivarle manualmente.
Una volta lanciato il programma di installazione, si consiglia di utilizzare l'opzione di Windows Update per assicurarsi che VMM 2008 sia aggiornato. Il programma di installazione analizza quindi le opzioni relative principalmente all'installazione del database SQL. In questo esempio viene utilizzato SQL Server 2005 Express Edition.
Successivamente, la procedura guidata chiede di identificare la posizione della libreria centralizzata. Questa può essere una directory locale sul server VMM (una condivisione viene creata per questa directory) oppure una condivisione file esistente. La posizione predefinita è C:\ProgramData\Virtual Machine Manager Library Files.
Il passaggio successivo consiste nell'assegnazione delle porte. A questo punto viene configurata la porta per la connessione della Console di amministrazione al servizio server VMM principale (8100 per impostazione predefinita), la porta utilizzata da WinRM per eseguire le funzioni di gestione (80 per impostazione predefinita) e la porta utilizzata dal Servizio trasferimento intelligente in background (BITS) per spostare i file sugli host della macchina virtuale (443 per impostazione predefinita). Una volta introdotte queste informazioni, viene visualizzata una schermata di riepilogo e l'installazione del server può terminare.
In seguito viene installata la Console di amministrazione dotata dei prerequisiti di sistema simili a quelli del server di VMM. L'unica opzione di configurazione disponibile oltre alla directory di installazione serve a confermare le porte di comunicazione utilizzate per connettersi al servizio server VMM. Questa porta deve essere la 8100, come configurato nell'installazione del server VMM.
Al termine dell'installazione, viene offerta l'opzione di creare un collegamento sul desktop per la Console di amministrazione e di aprire la console quando viene chiusa l'installazione. È consigliabile selezionare entrambe. Alla prima apertura della Console di amministrazione, si è invitati a collegarsi con il server. Con un'installazione su server singolo, il localhost sulla porta 8100 è corretto e si può premere Invio per avviare la console.
Infine, viene installato il portale self-service. I prerequisiti per il portale sono IIS 6.0 o 7.0, .NET Framework 3.0 e Windows PowerShell 1.0. (è richiesto Windows PowerShell poiché il portale self-service è solamente un'altra interfaccia per i servizi VMM principali che utilizzano Windows PowerShell). Per Windows Server 2008, è necessario attivare il ruolo IIS prima di avviare l'installazione di VMM 2008. Al momento di eseguire queste operazioni, assicurarsi che siano attivati i seguenti Servizi di Ruolo IIS:
  • Caratteristiche HTTP comuni (contenuto statico, documento predefinito, esplorazione directory, errori HTTP)
  • Sviluppo applicazione (ASP.NET, estendibilità .NET, estensioni ISAPI, filtri ISAPI)
  • Protezione (filtro richieste)
  • Compatibilità di gestione IIS 6.0
Se questi servizi di ruolo sono attivati, l'installazione passa alla verifica dei prerequisiti e l'installazione procede. Durante l'installazione, le opzioni di configurazione sono soltanto quelle relative alle porte utilizzate dal portale self-service. La prima porta da connettere al servizio VMM principale è 8100, la stessa della Console di amministrazione. La seconda è la porta su cui viene eseguito il portale. La predefinita è la porta 80 ma, in molte configurazioni, questa porta è già occupata e il programma di installazione di VMM genera un avviso. Se necessario, modificare la porta su una aperta, come ad esempio 8080. Il programma di installazione crea quindi un sito Web chiamato Home del Portale self-service di Microsoft System Center Virtual Machine Manager 2008. La configurazione può essere modificata in Server Manager.
Al termine dell'installazione di IIS, è possibile aprire il sito Web al localhost: 8080 in Internet Explorer. Se viene richiesta l'autenticazione quando viene aperto il sito Web, ciò è dovuto alle impostazioni di protezione di Internet Explorer. Il portale self-service deve essere eseguito nel contesto Intranet in Internet Explorer e potrebbe essere necessario aggiungere il server VMM all'elenco dei siti Intranet in Internet Explorer. Dopo aver completato le configurazioni, è possibile creare e utilizzare le macchine virtuali con self-service attivato in VMM 2008.

Aggiunta di host VMware ESX
Sebbene esistano numerose nuove funzionalità in VMM 2008, probabilmente la più attesa è l'aggiunta del supporto di gestione dell'host di VMware ESX. Grazie a questo supporto, VMM è ora in grado di gestire l'infrastruttura virtuale della maggior parte dei reparti IT aziendali.
Il processo di aggiunta degli host ESX nel Virtual Machine Manager 2008 è piuttosto semplice. Come già accennato, VMM 2008 gestisce gli host di VMware attraverso un server VirtualCenter, la cui versione deve essere 2.0.1 o 2.5. Per aggiungere i server VMware ESX nella console di gestione, è necessario semplicemente aggiungere il server VirtualCenter utilizzando l'azione Aggiungi VMware VirtualCenter Server localizzabile in alto a destra del riquadro Azioni.
Dopo aver lanciato la Procedura guidata, digitare il nome del computer del server VirtualCenter assieme all'account amministrativo per il server VirtualCenter. VMM aggiungerà gli host ESX, compresa la struttura del Gruppo host esistente da VirtualCenter, nell'interfaccia VMM. Questa operazione potrebbe richiedere vari minuti ma è possibile seguire lo stato di avanzamento dal menu di Processi di VMM.
Quando tutti i server sono stati importati, all'interno di VirtualCenter è possibile visualizzare la stessa struttura del server host di VMware ESX in VMM. Per aggiungere un altro server VirtualCenter, ripetere semplicemente il processo. Una volta aggiunta la struttura dell'host a VMM, è possibile aggiungere i server non-VMware nella stessa struttura di gruppo. I server non-VMware non saranno visualizzati in VirtualCenter.
Mentre VMM 2008 utilizza VirtualCenter per gestire gli host ESX, è necessario che sia in grado di accedere direttamente agli host ESX stessi per determinate funzioni, come V2V, stato di salvataggio e clonazione dagli host ESX. In questo modo, dopo aver aggiunto il server VirtualCenter in VMM, gli host appaiono come OK (Limitato). Per attivare l'intera gestione, andare alla pagina delle Proprietà dei singoli host ESX in VMM e fornire le credenziali appropriate dell'host per gestire direttamente i server.

Migrazione di VMotion
Quando si parla della gestione di VMware in Virtual Machine Manager 2008, si ripropone sempre la stessa domanda: VMM è in grado di eseguire VMotion e le altre funzioni di VirtualCenter? Dato che VMM utilizza VirtualCenter per la gestione di VMware, la risposta alla domanda è: sì!
Dal punto di vista funzionale, VMM tratta VMotion come qualsiasi altra migrazione. Per iniziare un VMotion, scegliere prima la macchina virtuale che si desidera spostare, quindi scegliere l'opzione della macchina virtuale Esegui migrazione dal riquadro Azioni sul lato destro di VMM. Successivamente, VMM visualizza la finestra di Posizionamento intelligente di quella macchina virtuale e presenta gli host di destinazione potenziali, con un tipo di trasferimento in diretta, come mostrato nella Figura 5. Il Posizionamento intelligente può aiutare a selezionare gli host di destinazione corretti per le macchine virtuali. Notare che il processo è lo stesso dell'esecuzione di una migrazione rapida utilizzando gli host di Hyper-V.
Figura 5 VMotion utilizzando il Posizionamento intelligente (fare clic sull'immagine per ingrandirla)
Scegliere l'host di destinazione per la macchina virtuale — in questo caso, è il server denominato cqaesxi003.contoso.com e fare clic su Avanti. La finestra di riepilogo finale, nella Figura 6, visualizza l'azione richiesta.
Figura 6 Finestra di riepilogo di VMotion (fare clic sull'immagine per ingrandirla)
Come affermato in precedenza, ogni procedura guidata in VMM presenta un pulsante Visualizza script che può visualizzare lo script Windows PowerShell per un lavoro nel Blocco Note. Ciò offre l'opportunità di osservare il funzionamento di Windows PowerShell con VMware in VMM 2008. Ecco lo script per questa 'azione:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
Tre comandi semplici eseguono il VMotion per questo sistema. In questo esempio, VM MyVM viene spostato dal server VMware cqaesxi003.contoso.com al server cqaesxi001.contoso.com. Il primo comando serve a identificare la macchina virtuale di cui va eseguita la migrazione via VMotion. Come si può notare, in questa riga di comando si assegna il valore della macchina virtuale alla variabile $VM:
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
Il secondo comando serve a identificare il sistema di host ESX di destinazione per la macchina virtuale. In questa linea si assegna la variabile $VMHost all'host ESX cqaesxi003.contoso.com:
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
Infine, si utilizza il comando Move-VM per muovere effettivamente la macchina virtuale. Ecco la riga di comando completa e i parametri per Move-VM:
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
In accordo con la filosofia di gestione eterogenea in Virtual Machine Manager, si può osservare che il comando non è un fornitore né un software specifico. Per completare il VMotion, emettere questo comando:
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
questo ordina a VMM di eseguire Move-VM rispetto alla macchina virtuale in $VM, spostandosi nel sistema di host in $VMHost, e di eseguire il lavoro in modo asincrono. Una volta iniziato il lavoro, l'intero processo può essere monitorato dal finestra Processi in VMM. Inoltre, questo stesso comando fondamentale può essere adoperato per migrazioni rapide sui cluster Hyper-V e anche per gli host non cluster, utilizzando un trasferimento basato su LAN.
Come si può notare, System Center Virtual Machine Manager 2008 ha ampliato le ottime funzionalità di Virtual Machine Manager 2007 aggiungendo nuove piattaforme di gestione e nuove funzioni. Riesaminando il processo di installazione e un paio di funzionalità, è stato dimostrato quanto sia semplice gestire gli hypervisor multipli in VMM 2008.
VMM 2008 è progettato per fungere da software di gestione consolidato per la virtualizzazione, unificando i sistemi fisici e virtuali da Microsoft e VMware. Con questa nuova versione di Virtual Machine Manager, gli amministratori di VMware, di Microsoft Virtual Server 2005 e del nuovo Hyper-V possono sfruttare un solo strumento, una sola interfaccia script e, soprattutto, un solo processo di gestione per la loro infrastruttura virtuale.

Edwin Yuen è Technical Product Manager nella divisione Windows Enterprise Management per System Center Virtual Machine Manager. Edwin ha iniziato a lavorare per Microsoft quando è stata acquisita la società Softricity, a luglio 2006. Edwin vanta anche un'esperienza di 13 anni nel settore della consulenza tecnica, sia in campo commerciale che legislativo. È laureato in ingegneria elettronica alla Johns Hopkins University.


Virtualizzazione
Introduzione a Microsoft Application Virtualization
Anthony Kinney

Questo articolo si basa su una versione non definitiva di App-V. Tutte le informazioni riportate sono soggette a modifica.
Panoramica:
  • Architettura di App-V
  • Gestione di applicazioni virtuali
  • Utilizzo del sequencer di App-V
  • Integrazione di App-V con Configuration Manager

Indice
Architettura di App-V
Funzionamento dell'infrastruttura completa di App-V
Aggiornamento di applicazioni virtuali
Sequenziazione
Versione 4.5
Microsoft Application Virtualization (o App-V) è un programma a cui sono particolarmente legato. App-V era in precedenza noto come SoftGrid e il sottoscritto è stato assunto in Microsoft grazie all'acquisizione di Softricity, l'azienda produttrice di SoftGrid. Ora sono lieto di avere l'opportunità di scrivere questo articolo per TechNet Magazine, poiché dal periodo dell'acquisizione sono avvenuti diversi cambiamenti.
L'approccio migliore ad App-V consiste nel descrivere dapprima le difficoltà che i professionisti IT devono affrontare in termini di gestione aziendale. Oggi i desktop aziendali sono sommersi di applicazioni. Prima di poter installare un'applicazione, è necessario eseguire interminabili test di regressione al fine di garantire che questa possa coesistere con le altre applicazioni installate sul sistema, senza danneggiarne la capacità di esecuzione. Quindi, prima di diventare effettivamente produttiva, l'applicazione deve essere sottoposta a una serie di processi di distribuzione. Inoltre, poiché un'applicazione è disponibile di fatto solo quando è installata, gli utenti sono legati a computer specifici. Questo complica ulteriormente progetti già di per sé critici e complessi, quali migrazioni di sistemi operativi e applicazioni, aggiornamenti della protezione e pianificazione dei ripristini di emergenza.
In questo ambito, App-V rappresenta una svolta. Grazie ad App-V, infatti, l'amministrazione di desktop si trasforma in un processo semplice e automatizzato, anziché richiedere una serie complicata di passaggi che implicano notevoli sforzi in termini di tempo e risorse. È quindi possibile distribuire, applicare patch, aggiornare e terminare le applicazioni con maggior facilità, ottenendo risultati migliori.
Con App-V, gli utenti possono utilizzare qualsiasi desktop per accedere alle proprie applicazioni. Queste sono distribuite su richiesta, ma vengono eseguite come se fossero realmente installate localmente. In tal modo non è necessario installarne i componenti o alterare il dispositivo host.
Questo utilizzo della virtualizzazione potrebbe modificare radicalmente il modo in cui i professionisti IT gestiscono i desktop. L'assenza di modifiche al dispositivo host e l'esecuzione di applicazioni virtualizzate introduce numerosi vantaggi, tra i quali:
  • Minor numero di conflitti tra applicazioni
  • Aggiornamenti delle applicazioni più semplici e rapidi
  • Possibilità di eseguire contemporaneamente più versioni della stessa applicazione
  • Applicazioni flessibili che seguono gli utenti in linea e non
  • Minore quantità di test di regressione tra applicazioni

Architettura di App-V
Esaminiamo ora le operazioni svolte "dietro le quinte" dalla piattaforma App-V. La piattaforma è costituita da alcuni componenti principali: un sequencer, un database, dei client, un server di gestione, un server di streaming e una console di gestione (vedere la Figura 1).
Figura 1 Layout di un ambiente App-V (fare clic sull'immagine per ingrandirla)
Il nucleo del sistema App-V è il client App-V. Esistono due tipi di client che è possibile utilizzare: il client Terminal Server e il client Desktop. In entrambi i casi il client deve essere installato su ciascun desktop e terminal server su cui si intende distribuire le applicazioni virtuali. Il client occupa una quantità relativamente ridotta di spazio su disco: installa un driver e dispone di un componente di runtime utente visibile, che viene visualizzato sotto forma di indicatore nell'area di notifica.
Il client acquisisce un elenco di applicazioni virtuali dal server di gestione di App-V e visualizza quelle disponibili. Si occupa quindi dell'avvio di tali applicazioni (quando avviate dall'utente) e gestisce la cache sul lato client. Il client gestisce inoltre la creazione dell'ambiente di runtime virtuale e garantisce che ciascun ambiente venga eseguito autonomamente. L'ambiente virtuale comprende diversi componenti, tra cui un registro di sistema, un file system e un gestore di servizi, tutti virtuali.
In App-V 4.5 sono disponibili tre opzioni per la distribuzione delle infrastrutture: infrastruttura completa, infrastruttura leggera e modalità autonoma. Quando si distribuisce un'infrastruttura completa, il back-end include il server di gestione e il server di streaming di App-V (quest'ultimo è un nuovo componente che sarà illustrato a breve). Il server di gestione di App-V ospita e distribuisce le applicazioni virtuali centralizzate, oltre ad aggiornarle quando vengono applicate patch o aggiornamenti.
Per supportare il database App-V, che contiene configurazioni e impostazioni per le applicazioni virtuali, il server di gestione è basato su SQL Server. Come strumento di gestione centrale per eseguire il provisioning e il controllo delle autorizzazioni per le applicazioni virtuali occorre utilizzare i gruppi di Active Directory.
Per gestire impostazioni e configurazione, la piattaforma di App-V fornisce un servizio Web Microsoft .NET Framework che è possibile caricare sullo stesso server, se l'IIS è installato. Questo servizio Web collega la console di gestione di App-V, uno snap-in MMC (Microsoft Management Console) e il database di App-V. Gli amministratori possono utilizzare la console per pubblicare e gestire applicazioni virtuali, assegnare gruppi Active Directory e controllare le impostazioni dei server, nonché eseguire generare sull'utilizzo di applicazioni virtualizzate (vedere la Figura 2).
Figura 2 Console di gestione (fare clic sull'immagine per ingrandirla)
L'infrastruttura leggera include il server di streaming di App-V, che consente l'esecuzione di funzionalità di streaming, quali l'aggiornamento a pacchetti/attivo. Questa opzione non richiede Active Directory o SQL Server, non dispone di un servizio di configurazione desktop, né di funzionalità di controllo licenze e misurazione. Questo tipo di infrastruttura consente, tuttavia, l'aggiunta di funzionalità di streaming a System Center Configuration Manager (SCCM) e ad altre soluzioni per la distribuzione del software aziendale (ESD) di terze parti.
In modalità autonoma il sequencer di App-V può creare un file MSI che automatizza l'aggiunta dell'applicazione virtuale (vedere la Figura 3). Il file MSI contiene metadati che consentono a qualsiasi sistema ESD di riconoscerlo e di controllare l'applicazione virtualizzata. A tal fine, il client deve passare alla modalità autonoma, che consente unicamente aggiornamenti basati su MSI delle applicazioni virtuali, mentre lo streaming non è consentito. Questa modalità permette alle aziende di utilizzare le funzionalità di isolamento di App-V.
Figura 3 Sequencer di App-V (fare clic sull'immagine per ingrandirla)
I file MSI sono molto flessibili, possono essere eseguiti in modalità del tutto autonoma con un unico client App-V e non necessitano di componenti server. Ciò significa che possono essere distribuiti manualmente, tramite un disco, o mediante qualsiasi strumento di distribuzione tradizionale.
In App-V 4.5, vengono ora supportati HTTP e HTTPS come protocolli per lo streaming. Questo garantisce prestazioni migliori a livello di streaming con un protocollo utilizzato su larga scala, in particolare per lo streaming in ambienti WAN protetti e Internet.

Funzionamento dell'infrastruttura completa di App-V
L'utente accede a un dispositivo su cui è installato uno dei client (client Desktop o Servizi terminal di App-V) e quest'ultimo invia al server una richiesta dell'elenco di applicazioni assegnate all'utente corrente. Il server comunica con Active Directory per determinare a quali gruppi appartiene l'utente, quindi restituisce l'elenco di applicazioni al client. Il client avvia la creazione di annunci per le applicazioni virtuali assegnate al determinato utente.
In questo processo di pubblicazione, vengono eseguite diverse operazioni:
  • Copia dei file di configurazione
  • Creazione delle icone desktop
  • Creazione dei collegamenti di invio
  • Creazione delle cartelle del menu di avvio
  • Configurazione dei tipi di file
Questo processo è molto rapido e, ancor più importante, garantisce che l'ambiente abbia esattamente lo stesso aspetto previsto dall'utente, senza alcuna modifica a livello di visualizzazione. Le applicazioni virtuali si comportano come se fossero installate a livello locale ma, naturalmente, non alterano il computer host. Le icone, anziché fare riferimento a file eseguibili che risiedono nella directory dei programmi, fanno riferimento al client App-V, che per la configurazione si basa su un file di avvio (un file OSD).
È importante sottolineare che questo processo ha un impatto minimo sulla rete poiché, a differenza delle distribuzioni software tradizionali, non vi sono elementi installati. I vantaggi che ne derivano sono enormi, in particolare in ambienti di utenti mobili, poiché le applicazioni sono disponibili all'utente, ma non vengono realmente distribuite fino all'avvio. Questo metodo di annuncio è ciò che consente ad App-V di disporre di applicazioni su richiesta e mobili.
Quando l'utente avvia un'applicazione virtuale, il client legge un file di configurazione OSD, che è stato memorizzato sul computer locale. Questo comunica al client il protocollo da utilizzare durante la comunicazione con il server di gestione di App-V, nonché il server su cui l'applicazione risiede.
Il server corrispondente risponde al client trasmettendo la soglia di avvio iniziale, che in genere corrisponde al 20-40% dell'applicazione completa. Quando l'intera soglia di avvio è stata trasmessa (anche in questo caso, circa il 20-40% dell'applicazione), l'applicazione virtuale è pronta per l'esecuzione.
Lo streaming è uno degli elementi principali del cambiamento paradigmatico introdotto con App-V, poiché consente di inviare una parte sufficiente di un'applicazione, in modo che questa possa essere eseguita senza perdere preziosa larghezza di banda della rete. Tutti i dati trasferiti al client risiedono in un file della cache locale sul dispositivo e tutti i successivi avvii dell'applicazione avverranno tramite la cache locale, eliminando eventuale traffico di rete aggiuntivo.
Al termine della trasmissione dell'applicazione, il client crea un ambiente isolato che evita che l'applicazione modifichi il computer locale (in altre parole, l'applicazione non ha footprint sul client). Il client, tuttavia, consente all'applicazione virtuale di accedere al file system locale quando si salvano e si modificano file e le permette inoltre di interagire con i servizi locali (ad esempio, la stampa), a condizione che l'utente disponga di privilegi adeguati sul sistema locale. Tuttavia, qualsiasi modifica eseguita da un'applicazione virtuale al registro di sistema e ai file del sistema locale viene reindirizzata all'ambiente virtualizzato, in modo che il dispositivo host rimanga inalterato.
Quando l'applicazione è in esecuzione, qualsiasi funzionalità che non sia stata utilizzata in precedenza viene fornita in base alle esigenze e memorizzata nella cache per utilizzo futuro. Il vantaggio offerto da questa operazione è che, all'avvio iniziale, vengono caricati solo i componenti di cui l'utente necessita, mentre le funzionalità superflue non consumano risorse di rete (nella nuova versione sono presenti alcuni miglioramenti a livello di memorizzazione nella cache sul lato client, che consentono un utilizzo più efficiente della cache e la possibilità di streaming in background).
Si consideri ad esempio Microsoft Office Word. Quasi tutti gli utenti utilizzano il correttore ortografico (senza il quale neppure questo articolo avrebbe potuto essere scritto), che quindi farà parte dell'avvio iniziale. Per quanto riguarda invece la funzionalità della Guida di Word, questa non viene utilizzata da altrettanti utenti, pertanto non viene fornita nell'avvio iniziale, ma inviata a ciascun utente al primo utilizzo.
Quando l'utente ha terminato e chiude l'applicazione, il client rimuove l'ambiente virtuale e memorizza tutte le impostazioni utente in una posizione specifica per l'utente: in tal modo, l'ambiente viene conservato e sarà ricostruito all'avvio seguente. La percentuale dell'applicazione virtuale trasmessa resta nella cache locale ed è disponibile per il successivo avvio. Se un altro utente accede allo stesso sistema host e avvia la stessa applicazione virtuale, questo potrà utilizzare l'applicazione già memorizzata nella cache.
Per rimuovere gli annunci delle applicazioni virtuali, è sufficiente rimuovere l'utente dal gruppo Active Directory appropriato. Inoltre, per disinstallare completamente l'applicazione virtuale da un desktop, è possibile eliminare semplicemente i dati della cache. Poiché l'applicazione non è mai stata realmente installata a livello locale, non vengono visualizzati messaggi con cui si richiede all'utente se desidera rimuovere i componenti condivisi.
Anche se un'applicazione virtuale è memorizzata in una cache, ciò non significa che tutti gli utenti possano accedervi. A differenza delle applicazioni installate a livello locale, in cui gli utenti possono semplicemente ricercare file eseguibili per i quali non dispongono di diritti, in questo caso non esistono rappresentazioni visive o fisiche dell'esistenza dell'applicazione virtuale, a meno che all'utente non siano stati concessi diritti espliciti mediante i gruppi Active Directory.

Aggiornamento di applicazioni virtuali
L'aggiornamento viene eseguito tramite il sequencer. Dopo l'aggiornamento di un'applicazione, questa viene collocata sul server di gestione di App-V accanto alla versione precedente. All'avvio seguente, il server notifica quindi al client che è stata apportata una modifica. Se la versione precedente è ancora in uso, l'utente continua ad aver accesso a tale versione finché l'applicazione virtuale non viene chiusa. All'avvio seguente, i delta che costituiscono l'aggiornamento vengono trasmessi al client e caricati nella cache, consentendo l'aggiornamento dell'applicazione.
Si supponga di avere 1.000 utenti che eseguono Word 2000. Un amministratore deve aggiornare Word 2000 (word2K.sft) a Word 2000 SP3, quindi copia il file word2K.sft nella postazione di sequenziazione e, nel sequencer, seleziona l'opzione di apertura per l'aggiornamento del pacchetto. Selezionando tale opzione, l'amministratore inizia a operare dallo stato dell'ultimo pacchetto. Può copiare DLL, effettuare aggiornamenti oppure eseguire patch all'interno dell'applicazione virtuale per aggiornarla a Word 2000 SP3, quindi salvare il pacchetto aggiornato.
Il sequencer assegna automaticamente un nuovo nome file, word2K_2.sft, per evitare nomi di file duplicati e per indicare la versione della sequenza. Il nuovo pacchetto viene collocato nella stessa directory del vecchio sul server di gestione di App-V, in modo che Word 2000 (word2K.sft) e Word 2000 SP3 (word2K_2.sft) risiedano nella stessa directory. L'amministratore utilizza quindi la console di gestione di App-V per collegare questi due file SFT.
Sul lato client, gli utenti con una sessione attiva di Word 2000 senza SP3 continuano a lavorare normalmente. Gli utenti che avviano una nuova sessione dell'applicazione dopo che l'amministratore ha eseguito questo collegamento riceveranno un messaggio che informa della modifica. Il client inizia quindi a trasferire solo le modifiche delta tra word2K.sft e word2K_2.sft, aggiornando automaticamente l'applicazione a Word 2000 SP3.
Grazie alla natura dinamica delle applicazioni virtuali, anche eseguire il rollback è piuttosto semplice. È sufficiente tornare alla console di gestione di App-V e rimuovere la versione aggiunta di recente. Ne consegue che, al riavvio, il client esegue il rollback alla versione precedente. Affinché non si verifichino sovrapposizioni di dati dei pacchetti, il client elimina automaticamente i dati dalla cache e trasmette nuovamente il file SFT corretto. Si tratta di un compromesso accettabile, se si considerano le operazioni necessarie per eseguire il rollback dell'aggiornamento di un'applicazione che è stata fisicamente installata utilizzando strumenti di distribuzione software più tradizionali.

Per comprendere i vantaggi di App-V, è necessario creare pacchetti di applicazioni virtuali. Qui entra in gioco il sequencer di App-V. Qualsiasi informazione ed esperienza nella creazione di script e pacchetti per strumenti di distribuzione software tradizionali faciliterà il passaggio alla sequenziazione (si noti che questa operazione richiederebbe di per sé un intero articolo).
La maggior parte delle soluzioni di distribuzione software si basano su script che acquisiscono la modalità di installazione di un'applicazione, per poi duplicare il processo su altri computer, eliminando l'esigenza di spostarsi di computer in computer per installare o aggiornare le applicazioni. Una volta installata l'applicazione, i comuni strumenti di distribuzione software ignorano il pacchetto. È quindi necessario installare eventuali dipendenze sulle quali l'applicazione potrebbe basarsi, eseguire altri script o effettuare operazioni manuali per configurare l'applicazione in base alle proprie esigenze.
La svolta fondamentale in App-V è che il processo di sequenziazione genera l'immagine di un'applicazione già installata, completa di relative dipendenze e configurazioni. Questa può essere "eseguita" dal client di App-V senza alterare il dispositivo sul quale avviene l'esecuzione.
Il sequencer genera una serie di file, il più importante dei quali è il file SFT, che contiene tutte le risorse e le dipendenze dell'applicazione, nonché le informazioni di configurazione. In alcuni casi potrebbe inoltre contenere più applicazioni: in effetti, le dimensioni del file possono diventare notevoli. Sono disponibili alcune opzioni di compressione, ma è essenziale una conoscenza approfondita delle prestazioni della propria rete e dei propri dispositivi. Il file icona (.ico) che il sequencer crea è utilizzato per annunciare l'applicazione virtuale, in modo che operi come se fosse installata a livello locale.
Anche il file OSD è molto importante e le relative opzioni sono infinite. Per impostazione predefinita, questo è un file basato su XML utilizzato per comunicare al client App-V come avviare l'applicazione virtuale. Il file può inoltre essere modificato per configurare e controllare la modalità di avvio ed esecuzione dell'applicazione virtuale. Per acquisire familiarità con le proprietà e i valori disponibili grazie al file OSD, è consigliata la lettura della guida per gli amministratori relativa alla sequenziazione e del documento sulle procedure consigliate in ambito di sequenziazione.
Infine, il nuovo file manifest.xml contiene informazioni di configurazione basate su pacchetti e può essere utilizzato per l'integrazione con soluzioni ESD di terze parti e distribuzioni MSI. Il sequencer può inoltre generare un file MSI per il pacchetto di applicazioni virtuali, che è possibile utilizzare per caricare le applicazioni su client autonomi (senza server) e attraverso un sistema ESD.
Il sequencer è uno strumento basato su una procedura, il packager, che guida l'utente attraverso il processo di installazione e di trasformazione di un'applicazione in un'applicazione virtuale (vedere la Figura 4). Il primo passaggio consente di configurare le proprietà predefinite per il pacchetto. Tali proprietà, memorizzate nel file OSD, comprendono nome del pacchetto e commenti. Alcune delle impostazioni avanzate consentono di specificare il server da cui eseguire il trasferimento, la directory dei contenuti e i sistemi operativi che il pacchetto deve supportare.
Figura 4 Procedura guidata di sequenziazione (fare clic sull'immagine per ingrandirla)
Il secondo passaggio consiste nell'installare, configurare e verificare l'applicazione. Durante l'installazione, il sequencer acquisisce tutte le modifiche apportate al sistema locale, compresi file system, Registro di sistema e sistema. La procedura guidata include inoltre alcune utilità che consentono, ad esempio, l'integrazione con Windows Update.
Il passaggio successivo prevede la configurazione delle associazioni dei tipi di file e la definizione della posizione dei collegamenti. Le posizioni standard includono il menu Start, il desktop e la barra di avvio rapido, ma è anche possibile creare posizioni personalizzate.
Quindi è necessario avviare l'applicazione e configurare la soglia per il lancio iniziale. In questo passaggio App-V determina la porzione iniziale dell'applicazione che deve essere fornita al client per consentirne l'avvio.
Per configurare questo codice iniziale (in genere indicato come Feature Block 1 o FB1), è sufficiente avviare l'applicazione e utilizzare le funzionalità in genere necessarie agli utenti. Ad esempio, avviare Word, quindi il correttore ortografico. Le DLL, i file o le chiavi di registro richiamate dall'applicazione durante questa fase vengono automaticamente designate come parte dell'FB1. I file, le impostazioni o i componenti non utilizzati in questa fase vengono aggiunti all'FB2. In seguito, quando l'applicazione viene utilizzata, il client riceve una mappa del file SFT, che indica i punti in cui inizia e termina l'FB1 e se sono presenti altri file nell'FB2, in modo che il client possa recuperarli quando sono necessari per l'applicazione.
Il passaggio finale del processo di sequenziazione consiste nell'accertarsi che tutto sia configurato correttamente. Nel sequencer viene visualizzata la finestra di dialogo illustrata nella Figura 5, che rappresenta l'SFT e consente di eseguire aggiunte finali o apportare modifiche al pacchetto.
Figura 5 Conferma e modifica di un pacchetto finale (fare clic sull'immagine per ingrandirla)

Versione 4.5
Dopo due anni di lavoro, nei prossimi mesi sarà rilasciato App-V 4.5. Si tratta della prima versione del prodotto a essere rilasciata da Microsoft e promette di aumentare la virtualizzazione delle applicazioni grazie all'introduzione di diversi miglioramenti di rilievo, quali interazione dinamica di applicazioni virtuali, scalabilità estesa e maggiore aderenza ai requisiti di protezione e internalizzazione Microsoft.
L'interazione dinamica di applicazioni virtuali consente alle applicazioni virtualizzate di interagire tra loro. Tale interazione è definita DSC (Dynamic Suite Composition) e non esclude la possibilità di aggiungere più applicazioni allo stesso pacchetto, costituendo invece un nuovo metodo per integrare dipendenze, middleware e plug-in condivisi tra applicazioni virtuali.
Gli amministratori possono specificare quali applicazioni virtualizzate possono interagire tra loro. Ad esempio, si supponga di disporre di cinque applicazioni Web che richiedono la stessa versione Java. In App-V 4.1, sarebbe necessario aggiungere questa versione Java a ciascuno dei cinque pacchetti separatamente. Si supponga inoltre che la versione Java richieda una patch, l'amministratore dovrebbe applicarla a tutti e cinque i pacchetti. Con DSC, Java può essere incorporato un'unica volta in un pacchetto, il quale può essere configurato per l'utilizzo da parte di tutte e cinque le applicazioni Web. Di conseguenza, per applicare la patch a Java, l'amministratore deve eseguire tale operazione sul pacchetto un'unica volta.
Lo stesso scenario è applicabile al middleware e ai plug-in. Quando Microsoft sarà prossima al rilascio e avrà finalizzato eventuali aggiunte, realizzerò un blog in cui verranno descritti altri casi di utilizzo.
I miglioramenti a livello di scalabilità comprendono sia l'infrastruttura di streaming, sia quella di back-end. I componenti di back-end sono stati modificati in modo da supportare in modo più efficiente scenari di clustering e failover, mentre lo streaming è più adatto a WAN e LAN. I miglioramenti sono stati possibili grazie a diverse aggiunte fondamentali.
Innanzitutto il nuovo componente "Streaming Server", che consente la trasmissione senza l'esigenza di un'infrastruttura di back-end di Active Directory e SQL Server. L'utente può usufruire dei notevoli vantaggi della distribuzione su richiesta e dell'aggiornamento centralizzato dei pacchetti, senza dover soddisfare i notevoli requisiti del back-end. Questo componente sarà largamente utilizzato in scenari che prevedono la presenza di filiali, nonché per l'integrazione di soluzioni ESD di terze parti.
Anche il client App-V è stato migliorato. Ad esempio, ora vengono memorizzate localmente tutte le informazioni relative all'utilizzo: in tal modo è possibile tenerne traccia, che il sistema client sia in rete o meno. Inoltre, la cache del client è stata espansa e migliorata per garantire prestazioni ottimali in scenari in cui lo spazio su disco è limitato. Infine, è stato aggiunto il supporto per la sequenziazione di applicazioni non in inglese, l'esecuzione di App-V su sistemi operativi non in inglese e la localizzazione in diverse altre lingue.

Integrazione di App-V con Configuration Manager
Sono stati progettati numerosi miglioramenti e nuove funzionalità in App-V 4.5 per l'integrazione della soluzione in SCCM 2007 R2. Come detto in precedenza, la virtualizzazione e lo streaming offrono possibilità di distribuzione delle applicazioni che i tradizionali strumenti di distribuzione software non offrono. App-V non sostituirà tali strumenti, tuttavia può completarli ed estenderli.
L'integrazione consentirebbe di ottenere tutte le funzioni di scalabilità, report, riconoscimento di dispositivi e WAN di SCCM e tutte le caratteristiche di streaming e isolamento di App-V. Di seguito sono indicate alcune delle aree che traggono vantaggio dall'integrazione delle due tecnologie.
Distribuzione di applicazioni: l'integrazione di SCCM R2 supporta tutte le funzionalità di distribuzione su richiesta, applicazioni mobili, soglie di avvio iniziale e distribuzione di applicazioni senza modificare i PC client.
Aggiornamenti: i punti di distribuzione (DP) SCCM consentono di distribuire modifiche delta di applicazioni virtuali quando i pacchetti vengono aggiornati. Questo introduce, a livello centralizzato, la possibilità di riportare le applicazioni virtualizzate alla versione precedente con un semplice clic.
Gestione: la versione R2 ha introdotto una nuova procedura guidata di annuncio delle applicazioni, che consente agli amministratori di distribuire applicazioni virtualizzate, nonché pacchetti software tradizionali e annunci da un'unica console.
Assemblaggio: non è necessario assemblare nuovamente le applicazioni quando si integra App-V con SCCM. La sequenziazione iniziale di un'applicazione deve essere eseguita utilizzando la sequenza App-V al di fuori di SCCM, ma gli amministratori possono aggiornare i pacchetti esistenti utilizzando SCCM.
Licenze: è possibile tenere traccia di licenze e misurazioni delle applicazioni virtuali utilizzando gli strumenti esistenti in SCCM.
BITS: SCCM offre un nuovo metodo per la distribuzione di applicazioni virtualizzate ad App-V tramite l'utilizzo del protocollo BITS standard del settore. Nonostante i DP SCCM possano eseguire la trasmissione, esistono casi in cui questo non è il metodo ideale per la distribuzione di applicazioni virtualizzate. Quando si esegue la distribuzione tramite SCCM, sono disponibili due opzioni. È possibile utilizzare funzionalità di streaming standard oppure funzionalità per la qualità del servizio (QoS) di BITS per eseguire la distribuzione in modo maggiormente controllato. Questo è inoltre utile in scenari nei quali si desidera caricare la cache prima che gli utenti lancino l'applicazione virtuale.
Distribuzioni a computer: SCCM offre la possibilità di distribuire applicazioni virtualizzate a computer specifici, nonché di continuare a supportare l'approccio basato sugli utenti della piattaforma App-V. Questo è vantaggioso quando si distribuiscono applicazioni virtuali a computer portatili, chioschi e computer di laboratorio. Risulta inoltre utile per fornire assistenza nel controllo delle licenze, nei casi in cui queste sono fornite ai dispositivi, non in base ai nomi degli utenti.
Scalabilità: l'esigenza di distribuire due strumenti separati che condividono una grande quantità di elementi è una questione di interesse comune. Integrando i vantaggi di SCCM, vale a dire scalabilità e WAN, con quelli di App-V, ossia isolamento e streaming, è possibile utilizzare l'SCCM esistente, che fornisce un unico strumento per occuparsi sia di gestione, sia di distribuzione, senza aggiungere ulteriore complessità.

Anthony Kinney è Technical Sales Professional responsabile del Microsoft Desktop Optimization Pack. Anthony è stato assunto da Microsoft nel 2006, con l'acquisizione di Softricity. Durante il periodo di lavoro presso Softricity, ha scritto e progettato il primo programma di formazione per SoftGrid (ora App-V). È possibile contattarlo all'indirizzo Anthony.kinney@microsoft.com.


Virtualizzazione
Ottenere una disponibilità elevata per Hyper-V
Steven Ekren
Panoramica:
  • Consolidamento dei server con Hyper-V
  • Garantire la disponibilità elevata delle macchine virtuali
  • Impostazione di un failover Windows Server 2008

Indice
Disponibilità elevata
Host e guest
Disponibilità dei guest
Ottenere la disponibilità elevata per le macchine virtuali
Prerequisiti
Procedura per ottenere la disponibilità elevata
Considerazioni
La virtualizzazione dei server è destinata ad avere un impatto significativo nei reparti IT delle aziende e, grazie a Hyper-V con Windows Server 2008, può diventare una realtà. Il consolidamento dei server in un numero minore di macchine fisiche offre enormi vantaggi in termini di risparmio di risorse e costi, ma bisogna considerare due aspetti fondamentali durante la pianificazione. Gli utenti hanno aspettative sempre crescenti circa la disponibilità del proprio software, tra cui applicazioni e strumenti line-of-business (LOB), come le piattaforme di messaggistica e collaborazione. Inoltre, eventuali problemi o guasti sui server possono avere un impatto considerevole sulle attività. Windows Server 2008 e Hyper-V forniscono una serie di soluzioni da implementare per ottenere la disponibilità elevata delle macchine virtuali, oltre alla possibilità di ospitare i carichi di lavoro nelle macchine virtuali.

Disponibilità elevata
Per disponibilità si intende la possibilità da parte gli utenti di accedere a un sistema per svolgere il proprio lavoro. La disponibilità elevata prevede che gli utenti possano accedere sempre a un sistema progettato e implementato in modo da garantire la continuità delle operazioni.
La disponibilità elevata per Hyper-V si ottiene con la funzionalità cluster di failover di Windows Server 2008. I tempi di inattività, sia pianificati che non pianificati, influiscono negativamente sulla disponibilità elevata, quindi il clustering di failover può aumentare in modo sensibile la disponibilità delle macchine virtuali in entrambi i casi.
Le macchine virtuali possono essere gestite dal cluster di failover che può essere utilizzato nelle macchine virtuali per monitorare e spostare i carichi di lavoro. Descriverò più in dettaglio entrambi gli scenari di configurazione, ma gran parte dell'articolo sarà dedicato alla gestione delle macchine virtuali. Prima di iniziare, consiglio di leggere l'intestazione laterale "Termini utili di Hyper-V" più in basso.

Host e guest
Su un sistema Hyper-V sono in esecuzione più sistemi operativi, quindi può essere difficile individuare con chiarezza di quale livello o sistema operativo si sta parlando. Utilizzerò il termine "guest" per indicare il sistema e l'ambiente all'interno di una macchina virtuale Hyper-V in esecuzione in una partizione figlio. Il termine "host", invece, indicherà la macchina fisica gestita dal sistema operativo sulla partizione padre di Hyper-V.
La disponibilità dell'host risolve i problemi legati al consolidamento dei server in cui, di fatto, si fa di tutt'erba un fascio. Il cluster di failover Windows Server 2008 può essere configurato sulla partizione padre di Hyper-V (host), in modo che le partizioni figlio di Hyper-V (macchine virtuali o guest) possano essere monitorate per la verifica dello stato e spostate tra i nodi del cluster. Questa configurazione ha i seguenti vantaggi:
  • Se la macchina fisica su cui sono in esecuzione Hyper-V e le macchine virtuali deve essere aggiornata, modificata o riavviata, le macchine virtuali possono essere spostate in altri nodi del cluster. Quando la macchina fisica tornerà a essere disponibile, le macchine virtuali potranno essere riportate alla posizione originale.
  • Se nella macchina fisica su cui sono in esecuzione Hyper-V e le macchine virtuali si verifica un guasto, ad esempio nella scheda madre, o se le prestazioni calano in maniera significativa, il cluster di failover Windows assumerà la proprietà delle macchine virtuali e le porterà automaticamente in linea.
  • Se si verifica un errore nella macchina virtuale, sarà possibile riavviarla sullo stesso server Hyper-V o spostarla su un altro server Hyper-V. Il cluster di failover di Windows Server rileva queste condizioni ed esegue le necessarie azioni di ripristino in base alle impostazioni nelle proprietà delle risorse della macchina virtuale. I tempi di inattività vengono ridotti al minimo grazie al rilevamento e ripristino automatico.
La Figura 1 illustra ciò che potrebbe accadere in tali situazioni. Inizialmente, la VM2 si trova sull'Host A, quindi viene spostata sull'Host B. Il nodo proprietario dell'archiviazione SAN LUN 2 passa dall'Host A all'Host B durante questo spostamento. Per fare in modo che la soluzione di disponibilità elevata soddisfi le esigenze dell'utente, occorre considerare attentamente dove posizionare le macchine virtuali. È bene considerare sia la capacità e che le prestazioni.
Figura 1 Una macchina virtuale e la relativa archiviazione vengono spostate in un nuovo host (fare clic sull'immagine per ingrandirla)
La capacità dei nodi dovrebbe essere sufficiente per ospitare tutte le macchine virtuali e ammortizzare il mancato funzionamento di X nodi o escluderne la partecipazione attiva al cluster. X indica il numero di nodi che il cluster può perdere, pur continuando a ospitare tutte le macchine virtuali. Per quel che riguarda la capacità, si può scegliere di tenere alcuni nodi di riserva che non ospitano regolarmente macchine virtuali. In alternativa si possono distribuire le macchine virtuali su tutti i nodi, in modo che ognuno disponga di una capacità sufficiente per assumere la proprietà delle macchine virtuali e avviarle qualora un numero X di nodi smetta di funzionare.
Per non influire sulle prestazioni quotidiane, è utile distribuire le macchine virtuali su tutti i nodi del cluster. Se si tengono alcuni nodi di riserva che non ospitano macchine virtuali, quelli che ne ospitano utilizzeranno più risorse, riducendo le prestazioni delle macchine virtuali e della partizione di gestione. La distribuzione delle macchine virtuali sui nodi ne riduce il carico e può garantire prestazioni migliori per le macchine virtuali e le partizioni di gestione. D'altra parte, può rendere più complessa la pianificazione della capacità. Possono rivelarsi utili software di gestione come System Center Virtual Machine Manager 2008, in grado di calcolare la capacità in caso di errori dei nodi e posizionamento delle macchine virtuali.

Disponibilità dei guest
Ma come si ottiene la disponibilità elevata per il carico di lavoro in esecuzione all'interno di una macchina virtuale? Di solito i carichi di lavoro comprendono server di file e di stampa, IIS e applicazioni LOB. L'analisi delle esigenze e delle soluzioni di disponibilità elevata per i carichi di lavoro all'interno delle macchine virtuali è molto simile a quella per i server autonomi. La soluzione dipende dal carico di lavoro specifico.
Alcuni carichi di lavoro possono ottenere la disponibilità elevata con Bilanciamento carico di rete (NLB) di Windows, che consente a più server di far parte di un pool con un nome di rete comune. I client effettuano una richiesta di connessione utilizzando questo nome di rete virtuale e si connettono a uno dei nodi del cluster NLB. Un caso tipico in cui si usa il clustering NLB è la creazione di Web farm con IIS: ciascun sistema dispone di IIS con le stesse pagine Web e accede agli stessi dati. NLB garantisce il bilanciamento del carico e consente di rimuovere i server per operazioni di manutenzione o nel caso in cui si verifichi un problema, assicurando così un buon livello di disponibilità elevata. Se una macchina virtuale Hyper-V esegue Windows Server 2008 (o una versione precedente di Windows Server con NLB), il guest può appartenere a un cluster NLB con altri guest sullo stesso host Hyper-V o su altri host.
I guest che eseguono Windows Server 2008 possono utilizzare la funzionalità del cluster di failover Windows per garantire la disponibilità elevata per i rispettivi carichi di lavoro. Sono molti i vantaggi offerti dall'utilizzo del clustering di failover Windows all'interno di un guest.
Controllo dello stato del carico di lavoro Il cluster di failover Windows è dotato di un monitor delle risorse che effettua chiamate alla DLL delle risorse associata al cluster. Viene controllato lo stato di ciascuna risorsa per verificare l'applicazione o il servizio gestito dalla risorsa, in modo da garantirne il corretto funzionamento. Questi controlli vengono definiti verifiche isAlive/looksAlive. Se la risorsa non risponde a una delle chiamate, la risorsa non sarà disponibile. A seconda della configurazione delle proprietà, la risorsa può tentare di riavviare il servizio o l'applicazione oppure può essere spostata su un altro nodo nel cluster di failover Windows.
Manutenzione delle macchine virtuali Qualora sia necessario modificare la configurazione delle macchine virtuali oppure il sistema operativo o il software devono essere aggiornati o modificati, è possibile spostare il carico di lavoro su un altro nodo del cluster. La macchina virtuale verrà arrestata o aggiornata senza interrompere troppo a lungo il servizio per gli utenti finali.
Manutenzione dei computer host Se la macchina fisica che ospita una macchina virtuale Hyper-V deve subire interventi di manutenzione o aggiornamenti software e gli altri membri del cluster di failover Windows si trovano su altri host Hyper-V, il carico di lavoro nella macchina virtuale può essere spostato su un altro nodo del cluster e la macchina virtuale può essere arrestata per applicare le modifiche o riavviare il server fisico.
Errori della macchina virtuale o del computer host Se si verifica un errore dell'host fisico Hyper-V o del guest della macchina virtuale, gli altri nodi del cluster di failover Windows rileveranno che il membro del cluster non risponde o non partecipa più al cluster, quindi i nodi rimasti porteranno in linea le applicazioni o i servizi in esecuzione sulla macchina virtuale su cui si è verificato l'errore.

Termini utili di Hyper-V
Di seguito è riportato un elenco di termini utili per definire i componenti o le funzioni di un sistema Hyper-V con disponibilità elevata (cluster di host).
Partizione padre A tutti i sistemi operativi in esecuzione su un server hypervisor vengono allocate risorse hardware che comprendono RAM, CPU e altri componenti di sistema. In Hyper-V la partizione che gestisce la configurazione delle risorse di hypervisor e sistema è detta partizione padre. Se si configura il ruolo Hyper-V e il server viene riavviato, l'installazione di Windows Server 2008 che aveva funzione di sistema operativo nativo sul sistema diventa il sistema operativo nella partizione padre del server Hyper-V.
Partizione figlio Un ambiente isolato su un server Hyper-V, configurato in modo da contenere un sistema operativo guest e fornire le risorse hardware a tale sistema operativo.
Host Hyper-V Il server fisico che ospita Hyper-V e il sistema operativo in esecuzione nella partizione padre.
Macchina virtuale Hyper-V Informazioni di configurazione e dati di Hyper-V utilizzati per avviare ed eseguire una partizione figlio di Hyper-V, comprese le informazioni di configurazione per creare la partizione figlio e i file VHD o dischi passthrough che ne contengono i dati.
Disco passthrough Una periferica di archiviazione esposta in Gestione disco come disco fisico assegnato esclusivamente a un guest Hyper-V. Il guest Hyper-V monta il disco e lo usa come fosse una periferica di archiviazione connessa localmente.
Disco rigido virtuale (VHD) Un file a cui ci si connette mediante una partizione figlio di Hyper-V e che è esposto al sistema operativo come periferica di archiviazione (disco). Il file .vhd si trova su una periferica di archiviazione montata dalla partizione padre e può essere una periferica di archiviazione connessa in maniera diretta o un'archiviazione connessa tramite SAN, NAS o SMB.
Ottenere la disponibilità elevata per le macchine virtuali
La configurazione della disponibilità elevata per una macchina virtuale è molto semplice, grazie anche alla creazione guidata dei ruoli in Gestione cluster di failover. Le macchine virtuali di Hyper-V hanno diversi componenti principali che occorre prendere in considerazione in caso di gestione per la disponibilità elevata. Di seguito sono riportati alcuni concetti fondamentali e prerequisiti generali.
Nodi cluster di failover Ogni server fisico che appartiene a un cluster di failover è detto "nodo". Per il clustering degli host il servizio Failover Cluster viene eseguito in Windows Server 2008 sulla partizione padre del sistema Hyper-V. Ciò consente di configurare la disponibilità elevata per le macchine virtuali in esecuzione sulle partizioni figlio all'interno degli stessi server fisici. Le macchine virtuali configurate per la disponibilità elevata saranno visualizzate come risorse nella console di Gestione cluster di failover.
Archiviazione per disponibilità elevata Le macchine virtuali con disponibilità elevata si possono configurare in modo da utilizzare dischi rigidi virtuali (VHD), dischi passthrough e dischi differenze. Per consentire lo spostamento delle macchine virtuali tra i vari nodi cluster di failover, deve esistere un'archiviazione (indicata come dischi in Gestione disco) a cui possano accedere tutti i nodi in grado di ospitare la macchina virtuale e che sia gestita dal servizio Failover Cluster. I dischi passthrough devono essere aggiunti al cluster di failover come risorse del disco, mentre i file VHD devono trovarsi sui dischi aggiunti al cluster di failover come risorse del disco.
Risorsa di macchina virtuale Questo è un tipo di risorsa di cluster di failover che rappresenta la macchina virtuale. Quando questa risorsa viene portata in linea, Hyper-V crea una partizione figlio e il sistema operativo nella macchina virtuale viene avviato. La funzione non in linea della risorsa rimuove la macchina virtuale da Hyper-V sul nodo in cui era ospitata e la partizione figlio viene rimossa dall'host Hyper-V. Se la macchina virtuale viene chiusa, arrestata o messa in stato salvato, questa risorsa verrà messa non in linea.
Risorsa per la configurazione di macchine virtuali Questo è un tipo di risorsa del cluster di failover utilizzata per gestire le informazioni di configurazione per una macchina virtuale. Esiste una risorsa di configurazione per ogni macchina virtuale. Una proprietà di questa risorsa contiene il percorso verso il file di configurazione che include tutte le informazioni necessarie per aggiungere la macchina virtuale all'host Hyper-V. Per avviare una risorsa di macchina virtuale, occorre accedere al file di configurazione. Poiché la configurazione è gestita da una risorsa a parte, è possibile modificare la configurazione di una risorsa di macchina virtuale anche se questa non è in linea.
Gruppo di servizi e applicazioni per macchine virtuali Per ottenere la disponibilità elevata di servizi o applicazioni attraverso il clustering di failover, è necessario che più risorse siano ospitate sullo stesso nodo cluster di failover. Per fare in modo che siano sempre sullo stesso nodo e interagiscano correttamente, le risorse vengono inserite in un gruppo a cui il cluster di failover Windows Server 2008 fa riferimento come "servizio" o "applicazione". La risorsa di macchina virtuale e quella per la configurazione si trovano sempre nello stesso gruppo di servizi o applicazioni. Possono esistere anche più risorse di disco fisico o di altri tipi di archiviazione che contengono dischi VHD, file di configurazione o dischi passthrough in un gruppo di servizi o applicazioni.
Dipendenze delle risorse È importante fare in modo che la risorsa di configurazione della macchina virtuale venga portata in linea (avviata) prima della risorsa di macchina virtuale e che venga portata non in linea (arrestata) dopo che la risorsa di macchina virtuale è stata portata non in linea. Per stabilire questo stato in linea/non in linea, impostare le proprietà della risorsa di macchina virtuale in modo che dipenda dalla risorsa di configurazione. Se esiste una risorsa di archiviazione che contiene il file per la risorsa di configurazione di macchina virtuale o per la risorsa di macchina virtuale, questa deve essere dipendente dalle risorse di archiviazione. Se, ad esempio, la macchina virtuale utilizza file VHD sul disco G: e sul disco H:, la risorsa di macchina virtuale deve dipendere dalla risorsa di file di configurazione e da quella per i dischi G: e H:.

Prerequisiti
Di seguito si riportano tre prerequisiti per ottenere la disponibilità elevata delle macchine virtuali di Hyper-V mediante la funzionalità di cluster di failover di Windows Server 2008.
  1. 1. Per ciascun nodo del cluster deve essere configurata la funzionalità di cluster di failover di Windows Server 2008. Per ulteriori informazioni sulla configurazione e la gestione dei cluster di failover, vedere l'intestazione laterale "Risorse di Hyper-V".
  2. 2. Il ruolo di Hyper-V deve essere installato. Gli aggiornamenti di Hyper-V devono essere installati e il ruolo deve essere configurato per ciascun nodo del cluster di failover (vedere sempre l'intestazione laterale "Risorse di Hyper-V"). Hyper-V dispone di un pacchetto di aggiornamento che installa i componenti server di Hyper-V; ne esiste anche un altro che installa la console di gestione di Hyper-V. Dopo l'installazione dell'aggiornamento per i componenti server di Hyper-V, il ruolo può essere aggiunto attraverso Server Manager o ServerManagerCMD.
  3. 3. Deve essere disponibile un'archiviazione condivisa per le macchine virtuali. L'archiviazione potrebbe essere gestita dal cluster di failover come tipo di risorsa di disco fisico incorporato; in alternativa, per gestire l'archiviazione condivisa si potrebbe utilizzare una soluzione di terze parti che supporti il cluster di failover di Windows Server 2008.

Procedura per ottenere la disponibilità elevata
Ecco la procedura per creare una soluzione per la disponibilità elevata. Occorre prima di tutto impostare una macchina virtuale. Configurare una macchina virtuale su uno dei nodi del cluster di failover in cui è installato il ruolo Hyper-V, utilizzando la console di gestione di Hyper-V (vedere la Figura 2). È possibile configurare manualmente una nuova macchina virtuale o importarne una già esistente. I dischi VHD devono trovarsi sul disco gestito dal cluster di failover di Windows Server 2008 e che è in linea sul nodo in cui viene configurata la macchina virtuale.
Figura 2 Configurazione di una macchina virtuale (fare clic sull'immagine per ingrandirla)
Occorre, quindi, arrestare la macchina virtuale chiudendo, disattivando o salvando lo stato. Solo le macchine virtuali arrestate possono essere configurate in modo da essere gestire dal cluster di failover.
Aprire la console Gestione cluster di failover (illustrata nella Figura 3) su qualsiasi server in cui è in esecuzione il ruolo di cluster di failover di Windows Server 2008 o su un client Windows Vista in cui sono in esecuzione gli Strumenti di amministrazione remota del server (RSAT). Per connettersi al cluster di failover, scegliere l'azione Gestisci un cluster… e selezionare un nodo o un nome di cluster oppure selezionare l'opzione per connettersi al cluster sul nodo in cui è in esecuzione la console.
Figura 3 Una macchina virtuale nella console di Gestione cluster di failover (fare clic sull'immagine per ingrandirla)
Dalla console di Gestione cluster di failover scegliere l'azione Configura servizio o applicazione…. Viene aperta la Configurazione guidata disponibilità elevata, mediante la quale è possibile configurare servizi, applicazioni o macchine virtuali in modo che siano gestiti dal cluster di failover. Nella pagina Selezione servizio o applicazione della procedura guidata scegliere Macchina virtuale, quindi Avanti.
Nella pagina Selezione macchina virtuale vengono visualizzate tutte le macchine virtuali configurate sui nodi del cluster di failover. Scegliere una macchina virtuale, quindi selezionare Avanti. Nella pagina Conferma della procedura guidata vengono riportati gli eventuali avvisi o errori. In questo passaggio la configurazione della macchina virtuale viene controllata per verificare che possa essere configurata come risorsa con disponibilità elevata e che i nodi possano ospitarla. Se si sceglie Avanti, la macchina virtuale viene aggiunta al cluster di failover come risorsa con disponibilità elevata.
La pagina Riepilogo contiene le informazioni e gli eventuali avvisi relativi ai risultati dell'aggiunta della macchina virtuale come risorsa con disponibilità elevata. Se si fa clic sul pulsante Visualizza rapporto…, vengono visualizzati i dettagli delle attività svolte per ottenere la disponibilità elevata per la macchina virtuale, oltre agli eventuali avvisi o errori. Scegliere Fine per chiudere la Configurazione guidata disponibilità elevata.
Come illustrato nella Figura 3, nella console Gestione cluster di failover è riportato un oggetto con il nome predefinito Virtual Machine(x) nel riquadro sinistro sotto il nome del cluster e in Servizi o Applicazioni. Scegliere la macchina virtuale da questa struttura ad albero. Le risorse che fanno parte del relativo gruppo di servizi o applicazioni saranno riportate nel riquadro centrale della console. Se altre macchine virtuali hanno dei file nella medesima archiviazione, queste verranno aggiunte al gruppo. Saranno visualizzate la macchina virtuale e le rispettive risorse di configurazione per ciascuna macchina virtuale inserita nel gruppo.
Nel riquadro delle informazioni per il gruppo di servizi o applicazioni vengono riportate le seguenti informazioni: Stato, Avvisi, Proprietari preferiti e Proprietario corrente. Il nodo Proprietario è quello in cui la macchina virtuale è configurata o in esecuzione. Selezionare l'azione Sposta macchine virtuali in un altro nodo per togliere dallo stato non in linea la macchina virtuale e riportarla in linea su un altro nodo. In genere conviene spostare una macchina virtuale su ogni nodo che può ospitarla nel cluster di failover, per verificare se lo spostamento è avvenuto e se la macchina virtuale viene avviata ed eseguita.

Risorse di Hyper-V
  • Descrizione dell'aggiornamento per la versione finale di Hyper-V per Windows Server 2008
  • Guida dettagliata per Hyper-V: Test di Hyper-V e clustering di failover
  • Introduzione a Clustering di failover di Windows Server 2008 (di Chuck Timon, TechNet Magazine, luglio 2008)
  • L'host Bilanciamento carico di rete non converge come previsto su macchine virtuali di Windows Server 2008 Hyper-V
  • Webcast su cluster Win2008
  • Criteri di supporto Microsoft per i cluster di failover di Windows Server 2008
Considerazioni
Ecco alcuni punti chiave da tenere ben presenti quando si configura la disponibilità elevata delle macchine virtuali.
Archiviazione Se utilizzano file VHD sullo stesso disco condiviso, le macchine virtuali saranno collocate nello stesso gruppo di servizi o applicazioni anche se si trovano su volumi diversi dello stesso disco. Uno dei vantaggi della condivisione dei dischi è che ottimizza l'uso dello spazio di archiviazione condiviso disponibile.
Lo svantaggio è che tutte le macchine virtuali verranno spostate ogni volta che se ne sposta una, ad esempio a causa di un ripristino automatico a seguito di un problema con la macchina virtuale o di una scelta dell'amministratore.
Lettere delle unità e GUID È possibile creare i volumi senza assegnare lettere alle unità. Le macchine virtuali possono utilizzare questi volumi, che a loro volta saranno gestiti dal cluster di failover. Se una risorsa del disco dispone di volumi che utilizzano GUID invece di lettere di unità, il GUID comparirà in Gestione cluster. Quando si creano le macchine virtuali e si specifica il percorso per i file VHD, è fondamentale accertarsi che il GUID nel percorso corrisponda a quello visualizzato in Gestione cluster per il volume. Se non corrisponde, la macchina virtuale potrebbe non essere avviata (portata in linea) sugli altri nodi del cluster di failover.
Esistono molti casi in cui i GUID non corrispondono. Se un volume è stato portato in linea sui nodi prima che fossero aggiunti come risorsa del disco gestito dal cluster di failover, il volume può avere un GUID diverso su ciascun nodo. È anche possibile che un volume abbia più GUID su un unico nodo. Se un disco viene aggiunto a un cluster di failover come risorsa di disco fisico, i GUID di volume in uso sul nodo in cui il disco è in linea verranno annotati nelle proprietà per la risorsa del disco.
I GUID per i volumi vengono aggiunti a un nodo quando la risorsa del disco viene portata in linea. Questo garantisce che il GUID specifico annotato dal cluster di failover per il volume sia un percorso valido su qualsiasi nodo che porta il disco in linea. Il nodo può avere altri GUID associati allo stesso volume. Di conseguenza, un utente potrebbe trovare un GUID che è valido per il volume su quel nodo, ma che non è lo stesso GUID che il cluster di failover assicura sia utilizzato per il volume sugli altri nodi. Il sintomo di questo problema è che una risorsa di macchina virtuale, di solito la risorsa di configurazione, non è in linea e viene visualizzato un messaggio di errore che indica che il percorso non è valido. Il percorso nel messaggio di errore specifica il GUID che non è gestito dal cluster per il volume.
Punto di montaggio Con Hyper-V e i cluster di failover si possono utilizzare i volumi montati su una cartella in un altro volume, invece di assegnare una lettera di unità o utilizzare un GUID. Poiché sia il volume montato sia quello che ospita il punto di montaggio devono trovarsi sullo stesso nodo cluster di failover, occorre fare in modo che tutti i dischi facciano parte del punto di montaggio nello stesso gruppo di servizio o applicazioni del cluster di failover.
Se i volumi sono sugli stessi dischi, ovviamente il problema non sussiste, al contrario di quanto accade quando i volumi si trovano su dischi diversi. È ovvio, ma va comunque sottolineato, che sia il volume montato che l'host del punto di montaggio devono trovarsi nell'archiviazione condivisa, configurata in modo da essere gestita dal cluster di failover.
Dischi differenze Tutti i file VHD che fanno parte di dischi differenze devono trovarsi nella memoria condivisa nello stesso gruppo di servizi o applicazioni della macchina virtuale che usa i dischi differenze. Nella configurazione più semplice, un disco differenze presenta due VHD: uno è il padre e include una serie di dati utilizzati come base, mentre l'altro è il figlio associato al padre.
Quando viene utilizzato per la prima volta, il disco differenze è identico al padre. Se i dati si trovano sul padre, vengono letti dal VHD corrispondente. Tutte le scritture avvengono nel VHD di figlio. Se i dati si trovano sul figlio, una lettura dei dati farà riferimento al VHD figlio.
Se una macchina virtuale è configurata in modo che il VHD figlio si trovi sull'archiviazione condivisa, ma il VHD padre non è sull'archiviazione condivisa nello stesso gruppo o si trova su una periferica di archiviazione connessa localmente, la macchina virtuale non verrà avviata (portata in linea) nel caso in cui venga spostata su un altro nodo. La Configurazione guidata disponibilità elevata controlla la corretta configurazione nella macchina virtuale e riporta un messaggio di errore qualora rilevi questo problema, ma vale la pena tener presente questo requisito nel caso in cui la configurazione di macchina virtuale sia stata modificata.

Steven Ekren è Senior Program Manager del team di Windows Server Failover Cluster and High Availability. Steven ha lavorato per 12 anni nel supporto tecnico di Microsoft, aiutando vari clienti aziendali a implementare e utilizzare i cluster di failover di Windows Server e tecnologie di virtualizzazione, tra cui Windows Hyper-V, System Center Virtual Machine Manager, Microsoft Virtual Server e Microsoft Virtual PC.


Virtualizzazione
Backup e ripristino di emergenza per la virtualizzazione server
Adam Fazio
Panoramica:
  • Considerazioni sulla pianificazione del ripristino di emergenza
  • Soluzioni a disponibilità elevata per il ripristino di emergenza
  • Backup e ripristino con Windows Server BackupItem

Indice
Pianificazione del ripristino di emergenza 101
Ripristino di emergenza e virtualizzazione
Conversione da macchina fisica a virtuale
Snapshot della macchina virtuale
Backup di Hyper-V
Windows Server Backup
Backup delle macchine virtuali con WSB
Considerazioni
Ripristino delle macchine virtuali con WSB
Data Protection Manager
Backup tramite script
DiskShadow
Conclusioni
Di fronte all'evoluzione e all'accresciuto utilizzo della tecnologia di virtualizzazione, le aziende iniziano a riconoscere che i vantaggi che ne derivano vanno ben oltre quelli più conosciuti, vale a dire: costi di infrastruttura ridotti e maggiore agilità IT. La nuova frontiera utilizza la piattaforma di virtualizzazione come strumento per realizzare o migliorare le strategie di ripristino di emergenza.
Perché la preparazione al ripristino di emergenza rappresenta uno dei temi più discussi nel settore IT? Da alcuni studi risulta che le aziende perdono in media dagli 80.000 ai 90.000 USD per ogni ora di inattività e che solo pochissime aziende che subiscono un'ingente perdita di dati riescono poi a sopravvivere a lungo termine. Il presente articolo contiene un'introduzione al ripristino di emergenza tramite la piattaforma di virtualizzazione di Microsoft, una descrizione dettagliata delle opzioni di backup e ripristino e, infine, alcune considerazioni relative a Windows Server 2008 Hyper-V.

Pianificazione del ripristino di emergenza 101
Il ripristino di emergenza rappresenta il processo di ripristino dei servizi critici che viene eseguito dopo un'interruzione dell'alimentazione. Tale processo dovrebbe far parte del piano di continuità di ogni azienda, il quale definisce le modalità in cui l'azienda continua a funzionare durante o in seguito a situazioni di emergenza. Questi piani rappresentano l'elemento fondamentale di qualsiasi iniziativa di ripristino di emergenza.
Alcuni fornitori sostengono che la propria tecnologia di automazione del ripristino di emergenza riduce al minimo o addirittura elimina la necessità di un piano dettagliato e collaudato. Sebbene sia possibile affermare che un sistema di automazione può migliorare i tempi di ripristino e ridurre la necessità dell'intervento umano, va tuttavia ricordato che non è possibile attenuare le conseguenze di una situazione di emergenza facendo ricorso esclusivamente alla tecnologia. Le persone e i processi sono importanti quanto le tecnologie.
Infatti, è praticamente impossibile scegliere le tecnologie corrette senza prima conoscere tutti i vincoli e gli obiettivi insiti in un processo di pianificazione del ripristino di emergenza. Lo scopo del presente articolo non è definire un intero piano di ripristino di emergenza, bensì sottolineare gli elementi fondamentali nella scelta delle tecnologie e implementazioni corrette. Pertanto, verranno analizzati brevemente alcuni driver tecnologici critici all'interno di un piano di ripristino di emergenza.
Definizioni di servizio e impostazione delle priorità Come viene definito esattamente il servizio completo che si desidera proteggere e qual è la sua importanza per l'organizzazione? Figura 1 mostra alcuni esempi di servizi aziendali che potrebbero essere inseriti in qualsiasi piano di ripristino di emergenza.
Figura 1 Esempio di definizioni di servizio e impostazione delle priorità
Servizio | Componenti primari | Dipendenze | Uso aziendale | SLA
Sito Web pubblico | Bilanciamento del carico di rete, tre server Web, due server database | DNS, rete, firewall, directory, sistema di archiviazione SAN (Storage Area Network) | Acquisto dei prodotti e rilevamento degli ordini; eCommerce; portale di assistenza clienti; informazioni aziendali | 99.99%
Sistema finanziario | Due server database, un server applicazioni | DNS, rete | Registrazione dei profitti aziendali, in ottemperanza alle leggi e alle normative vigenti | 99.99%
Sistema di posta elettronica | Tre server di posta elettronica, un server Web | DNS, rete, firewall, directory | Comunicazioni aziendali; assistenza clienti | 99.5%
Una volta definiti i servizi, è possibile iniziare ad identificare i sistemi e le dipendenze da destinare ai vari tipi di strategie di ripristino di emergenza. Dopo un attento esame dell'intera serie di servizi e dipendenze, potrebbe essere necessario prendere in considerazione diversi livelli di funzionalità di ripristino di emergenza. Infatti, un'unica soluzione di ripristino di emergenza per tutti i servizi mission-critical potrebbe risultare troppo costosa e complessa.
Contratti di servizio (SLA) Con SLA si intende un accordo o un contratto tra il provider di servizi (IT) e il cliente (l'azienda); tale documento definisce i valori soglia della disponibilità per un determinato servizio. Tali valori possono essere più o meno alti; ad esempio: "Il sistema di posta elettronica sarà disponibile per il 99,95% del tempo durante le normali ore lavorative e per il 98% del tempo durante le restanti ore del giorno, ad eccezione degli intervalli di manutenzione programmati, valori misurati mensilmente". In genere, gli SLA sono suddivisi in livelli ai quali è possibile assegnare servizi IT, misurati in base ad un periodo di tempo predefinito.
Contratti operativi (OLA) Gli OLA indicano, fondamentalmente, gli accordi stipulati tra diversi gruppi IT che collaborano all'attuazione di uno SLA e includono i tempi di elaborazione e di risposta per la distribuzione dei servizi. Si supponga di avere un sito Web mission-critical con un valore di soglia SLA pari al 99,99%, ma il database da cui dipende per il suo contenuto ha un valore soglia della disponibilità pari soltanto al 95%. Un OLA consente di individuare tali discrepanze e guida i team IT verso il raggiungimento di un obiettivo comune.
Recovery Point Objective (RPO) e Recovery Time Objective (RTO) Un RTO indica il periodo di tempo massimo in cui un servizio può non essere disponibile prima che si verifichi un'interruzione nella continuità; un RPO definisce il livello massimo della perdita di dati che l'azienda può sostenere. Se un servizio ha un SLA pari al 99% mensile, ne consegue che il suo RTO equivale a 7 ore e 18 minuti. Se si somma questo valore ad un RPO, ad esempio, di 24 ore è possibile definire con precisione tecniche di backup e pianificazioni.
Criteri di conservazione dei dati I criteri di conservazione dei dati di un'organizzazione specificano in maniera precisa la durata e la posizione di conservazione dei backup. In genere, sono regolamentati da requisiti legali e normativi.
Categorizzazione dei dati Occorre valutare anche la natura dei dati. Suddividendo i dati in categorie, risulta subito evidente che non tutti i dati richiedono lo stesso livello di considerazione del ripristino di emergenza. Ad esempio, un unico database potrebbe prevedere requisiti di disponibilità diversi rispetto a un'Active Directory con più controller di dominio, contenenti ciascuno una copia della directory. Allo stesso modo, i dati dei file server potrebbero prevedere procedure di ripristino molto diverse da quelle dei dati CRM.
Scenari di emergenza È importante definire tutti gli scenari che si desidera pianificare poiché ciascuno di essi comporta caratteristiche differenti, vale a dire procedure di ripristino, impatto sull'azienda e costi. È utile prendere in considerazione tutti gli scenari possibili e poi decidere su quali intervenire al momento della pianificazione di un ripristino di emergenza per il proprio ambiente:
  • Perdita di un intero sito
  • Perdita di un unico centro dati
  • Perdita di un sistema (errore sistema operativo o hardware)
  • Perdita di dati (eliminazione o danneggiamento dei dati)
  • Perdita di una dipendenza critica
Ovviamente, il recupero dalla perdita di un intero sito e quello di un solo sistema rappresentano situazioni ben diverse. È possibile anche che si desideri definire le soglie di ripristino in base ai propri SLA. Si immagini, ad esempio, che un intero sito non sia in linea a causa di una lunga interruzione della rete ISP. Se l'SLA per il servizio interessato prevede un tempo di 8 ore per il ripristino del servizio e 48 ore per il ripristino dei dati, si può decidere di eseguire alcune procedure di failover di servizio nel proprio sito di backup, senza tuttavia eseguire il processo di recupero dei dati poiché ciò anticiperebbe, in maniera piuttosto rapida, l'esecuzione del failback sul sito di produzione.
Wow! Tutta questa fatica e ancora non è stata analizzata la tecnologia! È bene non sottovalutare l'importanza critica della pianificazione. L'implementazione di un ripristino di emergenza senza alcun piano documentato è pura utopia.

Ripristino di emergenza e virtualizzazione
Ora che tutti gli elementi fondamentali per la pianificazione di un ripristino di emergenza sono stati analizzati, è necessario scoprire il ruolo della virtualizzazione. Molte aziende calcolano in minuti l'arco di tempo impiegato per il ripristino del servizio con server virtualizzati rispetto ai giorni o alle settimane necessari ai server fisici. Poiché oggi l'intero sistema operativo server è costituito semplicemente da una serie di file estratti dall'hardware fisico sottostante, si aprono nuovi orizzonti in termini di recuperabilità.
Secondo una teoria oggigiorno molto diffusa, grazie alle soluzioni di disponibilità elevata è possibile raggiungere alcuni o tutti gli obiettivi di ripristino di emergenza. L'idea alla base di tale convinzione è che in questo modo, in presenza di nodi cluster in posizioni fisiche separate con dati sincronizzati tra i siti, in caso di errore il nodo passivo è in grado di riprendere le operazioni consentendo il ripristino quasi in tempo reale.
Questo è vero, ma se si ripensa agli scenari di emergenza analizzati in precedenza è evidente che questa soluzione non è sempre attuabile. Per essere pronti ad affrontare tutti gli scenari possibili è necessaria una combinazione di tecnologie che solitamente prevede l'esecuzione di backup regolari. La disponibilità elevata non protegge da tutte le eventuali interruzioni di alimentazione e non elimina del tutto la necessità di una strategia di esecuzione di backup.
La disponibilità elevata con Hyper-V richiede l'attenta pianificazione del livello di archiviazione, fattore critico per l'esecuzione del recupero. Ad esempio, in un cluster Hyper-V con 2 nodi e archiviazione condivisa il sottosistema di archiviazione e i dati rappresentano un singolo punto di errore anche se i nodi cluster sono situati in datacenter separati.
Tuttavia, occorre ricordare che lo stesso cluster Hyper-V a 2 nodi con archiviazione non condivisa è in grado di far fronte alla perdita di dati o archiviazione su uno o sugli altri nodi. Ciò rende necessario l'utilizzo di tecnologie di replica al fine di mantenere l'archiviazione sincronizzata e implica inoltre una maggiore complessità (vedere la Figura 2).
Figura 2 Cluster Hyper-V multisito (fare clic sull'immagine per ingrandirla)
Esistono sviluppi molto interessanti nell'ambito della replica e della sincronizzazione dei dati, ma Microsoft, al momento, non se ne occupa. Nella pagina relativa al clustering multisito di Windows Server 2008 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) vale la pena dare un'occhiata ai partner indicati. Un'altra importante risorsa è il catalogo di Windows Server (vedere windowsservercatalog.com), che elenca i fornitori di soluzioni di archiviazione con tecnologie di replica certificate per Windows Server 2008.
Come si può osservare, esistono numerose configurazioni di archiviazione e disponibilità elevata da valutare. Anche in questo caso, è chiaro il motivo per cui occorre definire i propri requisiti aziendali e far sì che siano questi a determinare i requisiti tecnici piuttosto che il contrario.

Conversione da macchina fisica a virtuale
La virtualizzazione offre un'agilità di ripristino certamente unica, ma cosa dire dei sistemi fisici non adatti alla virtualizzazione? System Center Virtual Machine Manager (SCVMM) è in grado di eseguire conversioni da macchina fisica a virtuale (P2V) di server che eseguono Windows. Tale conversione determina la creazione di una macchina virtuale Hyper-V avviabile che rappresenta una copia esatta del server fisico di origine. Ora è possibile replicare questa macchina virtuale con le stesse modalità delle sue controparti virtualizzate all'interno di un'università o a livello nazionale e conseguire tempi di ripristino simili.
Questo approccio è diverso rispetto al tradizionale sistema di ripristino bare metal in quanto la posizione di ripristino non necessita più dello stesso numero o tipo di sistemi fisici come nel caso della posizione di produzione. È dunque possibile sottoscrivere in eccesso il proprio hardware di ripristino e scalarlo come necessario in base all'impatto della situazione di emergenza.
Sebbene SCVMM non contenga un'utilità di pianificazione per conversioni P2V, poiché la GUI viene eseguita interamente su Windows PowerShell, è possibile eseguirne facilmente lo script utilizzando il nuovo cmdlet P2V. Infatti, tutte le procedure guidate di SCVMM mostrano il codice utilizzato per eseguire un lavoro e quindi è possibile copiare il codice di un test P2V nel proprio ambiente e modificarlo per utilizzarlo automaticamente in futuro. La Figura 3 mostra alcuni codici di esempio; è possibile eseguire la procedura guidata P2V di SCVMM nel proprio ambiente per creare uno script Windows PowerShell univoco e personalizzabile.
Figura 3 Codice creato tramite la procedura guidata P2V di SCVMM
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

Snapshot della macchina virtuale
Sebbene dal punto di vista tecnico non si tratti di un backup, uno snapshot della macchina virtuale indica un punto temporale a cui ritornare utilizzando dischi differenze e una copia del file di configurazione della macchina virtuale. Una situazione in cui si verifica l'eliminazione accidentale dei dati all'interno della macchina virtuale, può essere considerata una funzionalità del ripristino di emergenza in quanto è possibile eseguire il rollback della macchina virtuale per recuperare lo snapshot e risolvere il problema. (In seguito, viene offerta una breve analisi degli snapshot del servizio Copia Shadow del volume o VSS).

Backup di Hyper-V
Backup basati su host Uno dei vantaggi più straordinari offerti dalla virtualizzazione server è la prospettiva di non dover più eseguire il backup individuale dei sistemi virtualizzati. Poiché questi sistemi sono costituiti semplicemente da file presenti in un file system dell'host, basta eseguire il backup dei file, giusto? Non esattamente. Poiché stiamo parlando di live computer composti da dati in memoria, dati su disco, configurazioni di sistema e file aperti, occorre prendere in considerazione quanto segue. Come è possibile garantire la coerenza dei dati di backup alla luce di tutti questi elementi?
Un miglioramento significativo della storia del backup in Windows Server si è ottenuto con Windows Server 2003 e con l'avvento di VSS che fornisce una serie standard di API estendibili che i writer VSS (hook in applicazioni e servizi che aiutano a fornire copie shadow coerenti) utilizzano per creare backup di file aperti e di applicazioni. Con l'aiuto del servizio VSS, di fornitori e writer, l'applicazione di backup può creare molto velocemente una copia riferita a un momento temporale specifico di un volume che l'applicazione riconosce e può quindi elaborare adeguatamente.
Hyper-V dispone del proprio writer VSS che consente ai produttori di software di creare straordinarie soluzioni di backup. Il writer consente alle applicazioni di backup di eseguire backup VSS basati su host delle macchine virtuali in esecuzione. Se i componenti di integrazione Hyper-V e il servizio VSS (disponibile in Windows XP SP1 e Windows Server 2003 e versioni successive) sono installati su un sistema operativo eseguito all'interno della macchina virtuale, il backup basato su host ha luogo come se venisse eseguito all'interno del guest; il backup viene eseguito con la macchina virtuale in esecuzione e i dati risultano coerenti (vedere la Figura 4).
Figura 4 Backup VSS (fare clic sull'immagine per ingrandirla)
Tuttavia, se il sistema operativo guest non supporta i componenti di integrazione né VSS, per l'esecuzione del processo di backup è necessario che la macchina guest sia posta in stato salvato e che si ottenga uno snapshot VSS basato su host dei file di dati della macchina virtuale. Tale snapshot può essere utilizzato per il ripristino temporizzato. Gli snapshot VSS in stato salvato saranno esposti ad un determinato tempo di inattività della macchina virtuale (che può variare dai 5 ai 10 minuti), mentre tutte le procedure di backup su nastro vengono eseguite in rapporto alla copia VSS dei dati.
Backup basati su guest In un ambiente fisico il backup dei server e delle applicazioni deve essere eseguito singolarmente. Backup di questo genere possono continuare in un datacenter virtualizzato. In tale contesto, eseguendo il backup di una macchina virtuale occorre tener presente sempre le stesse considerazioni ossia i requisiti della capacità di rete per backup basati sulla rete e l'impatto delle prestazioni sul sistema durante la finestra di backup. Per quanto riguarda i backup basati su guest, è possibile scegliere di utilizzare una NIC fisica dedicata nell'host associata a una rete virtuale utilizzata da tutti i guest.

Windows Server Backup
Windows Server 2008 contiene Windows Server Backup (WSB) con supporto VSS che può essere utilizzato per eseguire backup Hyper-V basati su host e su guest delle proprie macchine virtuali. Poiché del tutto in grado di utilizzare VSS, tale soluzione può eseguire backup basati su host delle macchine virtuali in esecuzione, di gran lunga l'opzione migliore.
Nel caso in cui si disponga di macchine virtuali prive di componenti di integrazione installati, VSS non viene utilizzato. In tal caso, si può scegliere tra un paio di opzioni. È possibile continuare ad utilizzare WSB per eseguire il backup di una macchina virtuale in cui i componenti di integrazione non sono stati installati. Ciò implica il salvataggio dello stato della macchina virtuale e il successivo prelievo, da parte del backup, dei dischi virtuali e dei file di configurazione della macchina virtuale.
Tuttavia, questa soluzione non è consigliabile nel caso di un'applicazione Exchange poiché essa non è in grado di riconoscere l'esecuzione di un backup e i registri delle applicazioni non vengono troncati. Inoltre, la macchina virtuale è soggetta a tempi di inattività che variano a seconda del tempo impiegato per il backup.
In alternativa, è possibile eseguire un backup dall'interno della macchina virtuale, proprio come se si trattasse di una macchina fisica, utilizzando NTBackup o WSB a seconda del sistema operativo installato nella macchina. Di seguito sono riportate le modalità di utilizzo di WSB per i guest supportati che dispongono di componenti di integrazione installati.

Backup delle macchine virtuali con WSB
Hyper-V non registra automaticamente il proprio writer VSS per l'utilizzo con WSB. Occorre aggiungere manualmente il valore e la chiave del Registro di sistema illustrati nella Figura 5 prima che WSB possa supportare un backup Hyper-V. È possibile aggiungerli nella riga di comando come indicato di seguito:
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
Figura 5 Chiave e valore per la registrazione del writer VSS di Hyper-V
Percorso | Valore o chiave del Registro di sistema | Tipo
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | Chiave | n\a
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | Valore | REG_SZ (Hyper-V, ad esempio)
Tale procedura non richiede il riavvio della macchina, poiché WSBricerca tale valore/chiave in fase di runtime del backup. Il seguente comando mostra se la voce è stata impostata:
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
Ecco come installare WSB. Fare clic su Start | Server Manager. Nel riquadro sinistro fare clic su Funzionalità, quindi su Aggiungi funzionalità nel riquadro destro. Nella pagina Seleziona funzionalità, aprire la finestra Funzionalità di Windows Server Backup e spuntare le caselle di controllo Windows Server Backup e Strumenti di riga di comando. Per configurare il backup, effettuare la seguente procedura:
  1. Fare clic su Start | Strumenti di amministrazione | Windows Server Backup.
  2. In caso di backup di un host remoto, scegliere Connetti ad un altro computer e digitare l'host Hyper-V.
  3. Scegliere Backup unico o Pianificazione backup.
  4. Selezionare la configurazione del backup — Server completo o Personalizzato. Se si sceglie l'opzione Personalizzato, accertarsi di disporre di tutti i volumi che contengono dati relativi alla macchina virtuale sottoposta a backup, compresi i dati di configurazione della macchina virtuale, i dischi virtuali e gli snapshot.
  5. Scegliere la posizione di memorizzazione del backup.
  6. Scegliere Backup completo del servizio Copia Shadow del volume o Copia di backup del servizio Copia Shadow del volume. In caso di backup basati su host in cui non si eseguono altri backup con le macchine virtuali, scegliere Backup completo del servizio Copia Shadow del volume.
  7. Una volta confermati i dettagli, selezionare Backup.
Considerazioni
  • È necessario eseguire il backup di tutti i volumi relativi ad una macchina virtuale, compresi i dischi rigidi virtuali (VHD), i file di configurazione della macchina virtuale e gli snapshot.
  • Se si sta creando una Pianificazione backup, occorre utilizzare un volume locale dedicato che verrà formattato e utilizzato esclusivamente da WSB. Al contrario, se si sceglie l'opzione Backup unico, è possibile memorizzare il backup su un volume locale non dedicato, su un dispositivo rimovibile o su una condivisione di rete.
  • Se nella macchina virtuale sottoposta a backup non sono stati installati i componenti di integrazione, WSB salverà lo stato della macchina virtuale in esecuzione al fine di garantire la coerenza dei dati di backup.
  • Al termine dell'operazione, il set di backup è portatile e può essere utilizzato con qualsiasi host Hyper-V.
Ripristino delle macchine virtuali con WSB
Sebbene WSB sia in grado di ripristinare file singoli, questa funzionalità non prevede l'utilizzo di VSS e potrebbe determinare quindi un ripristino non coerente se la macchina virtuale era in esecuzione durante il backup. Per eseguire il ripristino della macchina virtuale in esecuzione occorre ripristinare l'intero volume.
A questo scopo, è necessario selezionare Start | Strumenti di amministrazione | Windows Server Backup e, nel riquadro Azioni, selezionare Ripristino. Selezionare il server da cui recuperare i dati (quello dove si trovano i dati di backup WSB), quindi scegliere la data a partire dalla quale recuperare i dati. Ora è possibile scegliere il tipo di ripristino.
A questo punto occorre prendere una decisione. Se si ha bisogno dell'intera macchina virtuale, compresi configurazione, snapshot e dischi virtuali (nel caso, ad esempio, di un guasto totale all'host), selezionare Ripristino dell'applicazione, quindi Hyper-V, come mostrato nella Figura 6. In questo caso non è disponibile l'opzione per il ripristino dei singoli file. Sarà necessario ripristinare l'intero contenuto di quel set di backup. Si noti che in questo modo non verranno sovrascritti i dati relativi alla configurazione esistente di Hyper-V e della macchina virtuale che sono stati modificati dal backup.
Figura 6 Ripristino di un backup Hyper-V (fare clic sull'immagine per ingrandirla)
Se si ha bisogno solo del VHD e i dati di configurazione e gli snapshot della macchina virtuale sono integri, è possibile selezionare File e cartelle e selezionare il singolo file VHD necessario. Si noti che questo processo non utilizza il writer VSS; la macchina virtuale dovrebbe essere stata sottoposta a backup tenendo conto di questo fatto, avendo salvato in primo luogo il suo stato.
In caso di perdita totale di sistema e dati e qualora sia necessario ripristinare l'host Hyper-V, compreso il sistema operativo di Windows Server 2008 e tutte le relative macchine virtuali in esecuzione, occorre attivare Ambiente ripristino Windows, quindi eseguire il ripristino. Questa operazione può essere effettuata tramite il disco di installazione di Windows Server 2008 o una partizione del disco preconfigurata.

Data Protection Manager
Sono stati analizzati i passaggi necessari all'esecuzione del backup e del ripristino tramite la soluzione WSB, affidabile, gratuita e incorporata, con alcune considerazioni su host e guest Hyper-V; tuttavia, WSB non rappresenta una soluzione per la protezione dati di livello aziendale. Ecco dunque la soluzione Data Protection Manager (DPM) 2007 SP1. La sua uscita è prevista per la fine del 2008 e DPM SP1 supporterà Hyper-V e alcune straordinarie funzionalità:
  • Un'unica console di gestione per tutti gli host e i guest Hyper-V.
  • Protezione dei dati continua che distanzia gli snapshot VSS ad intervalli fino a 15 minuti evidenziando solamente i bit modificati nel processo.
  • Abilitazione per i cluster Hyper-V che consente al backup di seguire la macchina virtuale ma mano che questa si sposta tra i nodi cluster.
•Server DPM per la replica di server DPM.
  • Supporto per disco e nastro (da disco a disco, da disco a nastro o da disco o disco a nastro).
  • Funzionalità di backup e di ripristino per l'intera gamma di dati compresi host e guest Hyper-V; backup VSS senza agente di guest in esecuzione; supporto del ripristino di singole macchine virtuali; dati cluster di failover e migliori funzionalità specifiche delle applicazioni per SQL Server, Exchange, SharePoint, Hyper-V e Virtual Server.
  • Script eseguiti precedentemente e successivamente al backup.
Se al momento si utilizza una soluzione di backup di terzi si consiglia di controllare la disponibilità di aggiornamenti per l'applicazione; la maggior parte dei fornitori si sta impegnando al massimo per lanciare sul mercato soluzioni Hyper-V basate su host.

Backup tramite script
WSB contiene un'interfaccia della riga di comando, WBadmin.exe, nonché una serie di cmdlet Windows PowerShell da utilizzare nell'esecuzione di script. Quando si utilizzano questi ultimi, valgono le stesse regole di backup illustrate precedentemente, oltre alla necessità di registrare manualmente il writer VSS Hyper-V nel registro.
La Figura 7 mostra alcuni comandi WBAdmin. Per la documentazione WBAdmin completa vedere go.microsoft.com/fwlink/?LinkId=124380. Come si può notare, WBAdmin non contiene alcuna funzione per la configurazione dei criteri di backup, ma è disponibile uno snap-in Windows PowerShell per la gestione di queste impostazioni. È possibile verificare se questo snap-in è registrato con il seguente comando:
Get-PSSnapin -Registered
Figura 7 Comandi WBAdmin
Comandi WBAdmin | Descrizione
ENABLE BACKUP | Attivare o modifica un backup quotidiano pianificato.
DISABLE BACKUP | Disattiva l'esecuzione di backup quotidiani pianificati.
START BACKUP | Esegue un backup.
STOP JOB | Interrompe l'esecuzione del backup o del ripristino.
GET VERSIONS | Elenca i dettagli dei backup recuperabili da una specifica posizione.
GET ITEMS | Elenca gli elementi contenuti nel backup.
START RECOVERY | Esegue un ripristino.
GET STATUS | Riferisce lo stato del lavoro in esecuzione.
GET DISKS | Elenca i dischetti attualmente in linea.
START SYSTEMSTATERECOVERY | Esegue un ripristino dello stato del sistema.
START SYSTEMSTATEBACKUP | Esegue un backup dello stato del sistema.
DELETE SYSTEMSTATEBACKUP | Cancella il/i backup dello stato del sistema.
È possibile utilizzare quanto segue per caricare lo snap-in Windows.ServerBackup:
Add-PSSnapin windows.serverBackup
Una volta caricato, è possibile accedere ai cmdlet di Windows PowerShell per WSB come illustrato nella Figura 8. Per una descrizione dettagliata di ciascun cmdlet eseguire questo comando:
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
Figura 8 Cmdlet di Windows Server Backup
Cmdlet | Descrizione
Add-WBBackupTarget | Aggiunge una destinazione di backup ai criteri di backup.
Add-WBVolume | Aggiunge un volume ai criteri di backup.
Get-WBBackupTarget | Ottiene destinazioni di backup da un criterio.
Get-WBDisk | Ottiene tutti i dischi.
Get-WBPolicy | Ottiene i criteri di backup correnti.
Get-WBSchedule | Ottiene la pianificazione dei backup prevista dai criteri.
Get-WBSummary | Ottiene la cronologia e il riepilogo dei backup.
Get-WBVolume | Ottiene tutti i volumi.
New-WBBackupTarget | Crea una nuova destinazione di backup.
New-WBPolicy | Crea un nuovo criterio vuoto.
Remove-WBBackupTarget | Rimuove una destinazione di backup dai criteri.
Remove-WBPolicy | Elimina i criteri di backup.
Remove-WBVolume | Rimuove un volume dai criteri.
Set-WBPolicy | Salva l'oggetto WBPolicy per creare un backup pianificato.
Set-WBSchedule | Imposta la pianificazione secondo criteri di backup.

Esiste un'altra utilità incorporata in Windows Server 2008 che può utilizzare il writer VSS Hyper-V e che conferisce alle opzioni di scripting una maggiore flessibilità. DiskShadow.exe consente di creare una copia shadow e di installarla come un'unità; ciò permette agli amministratori di eseguire un backup più selettivo rispetto a quello possibile con WSB. È importante ricordare che DiskShadow non accetta l'input della pipeline di Windows PowerShell; richiede, invece, che i comandi vengano impartiti mediante uno script. Il risultato potrebbe essere simile a quanto indicato di seguito:
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
Questo script cancella dapprima qualsiasi copia shadow esistente nell'unità C: e, successivamente, garantisce che la copia shadow verrà mantenuta dopo l'esecuzione di DiskShadow, infine, crea un blocco transazionale. Se uno dei passaggi non riesce, l'intero processo fallisce. In questo blocco, DiskShadow verifica che il writer per Hyper-V sia caricato e aggiunge l'unità C: all'elenco di unità da sottoporre a backup.
L'unità C: riceve un GUID per l'identificazione e questo GUID viene memorizzato in una variabile di ambiente denominata "MyShadow". Una volta completata questa operazione, viene creata la copia shadow.
Il backup è esposto come unità X: utilizzando la variabile di ambiente. con i dati su X: è possibile effettuare diverse operazioni, poi è possibile eseguire nuovamente DiskShadow utilizzando il comando Unexpose X: per rimuovere l'unità.
Si noti che il ripristino delle macchine virtuali Hyper-V sottoposte a backup con DiskShadow è al momento un processo manuale (la macchina virtuale deve essere creata di nuovo, gli snapshot non vengono conservati e così via). Sebbene ciò presenti alcuni ovvi svantaggi, i dati sono protetti.
Il ripristino di emergenza può essere un processo difficile e apparentemente interminabile. Tuttavia, la virtualizzazione server apre la strada a nuove possibilità, grazie alle tecnologie e al risultante punto di ingresso a basso costo. Microsoft fornisce non solo la virtualizzazione ma un intero ecosistema. La piattaforma di virtualizzazione server e la famiglia System Center offrono soluzioni più olistiche alle problematiche sempre più complesse che le organizzazioni si trovano ad affrontare, compreso il ripristino di emergenza.
Colgo l'occasione per ringraziare James O'Neill per il prezioso contributo apportato a questo articolo.

Adam Fazio ha iniziato a lavorare per Microsoft Consulting Services più di 2 anni fa e ora si occupa della divisione Public Sector negli Stati Uniti. Lavora nel settore IT da più di 10 anni e ha partecipato a diversi progetti di infrastrutture e datacenter per Fortune 100s fino agli start-ups di Internet. Attualmente, è il responsabile delle escalation tecniche per il programma globale relativo alla distribuzione rapida della virtualizzazione di Microsoft.


Virtualizzazione
Strumenti essenziali per la pianificazione della tua infrastruttura virtuale
Jay Sauls e Baldwin Ng
Panoramica:
  • Contenimento dei costi
  • Inventario dei computer
  • Determinazione dell'utilizzo di CPU, I/O del disco e rete

Indice
Caratteristiche principali dello strumento
Analisi della situazione
Determinazione degli utilizzi attuali
Consigli sul posizionamento dei server
Configurazione delle macchine virtuali
Vincoli di posizionamento
Valutazione delle opzioni
Requisiti
Conclusioni
Pur non rappresentando una novità assoluta, la virtualizzazione si sta affermando in molte nuove aree, ben lontane dall'originaria virtualizzazione delle piattaforme sviluppata da IBM negli anni 1960. Una delle principali ragioni di questa rapida crescita è il potenziale offerto dalle tecnologie di virtualizzazione in termini di contenimento dei costi nel datacenter e nelle operazioni informatiche. A causa dell'aumento dei costi dell'energia e della crescente richiesta di servizi informatici da parte di diversi dipartimenti della propria organizzazione potrebbe diventare difficile tenere il passo con la crescita dei server e, contemporaneamente, tenere sotto controllo i costi operativi. La virtualizzazione può essere utile in scenari di questo tipo. Microsoft e altri produttori di software hanno sviluppato nuove tecnologie, tra cui la virtualizzazione di server, desktop e applicazioni, che renderanno le risorse virtuali maggiormente disponibili.
In questo articolo si prende in esame un set di strumenti utili per i progetti di virtualizzazione: Microsoft Assessment and Planning Toolkit (MAP), componente della famiglia Microsoft Solution Accelerator. Cosa sono gli acceleratori di soluzioni? In termini semplici, sono strumenti di automazione e guida utili per qualsiasi progetto informatico. Gli acceleratori di soluzioni sono risorse gratuite e affidabili che aiutano a pianificare, creare e gestire in modo proattivo l'infrastruttura IT, dai desktop ai server, dalle macchine fisiche a quelle virtuali.
Progettati in collaborazione con gli esperti del settore e verificati in ambienti cliente reali, gli acceleratori di soluzioni offrono la giusta quantità di indicazioni normative e automazione per ottenere elevate prestazioni e creare un'infrastruttura IT indipendente dai prodotti, il tutto senza dover reinventare la ruota. Queste risorse si concentrano sugli interessi cruciali di aziende di ogni dimensione, come valutazione e pianificazione delle infrastrutture, virtualizzazione, comunicazione e collaborazione, protezione e conformità.

Caratteristiche principali dello strumento
Toolkit MAP 3.1, rilasciato di recente, (vedere la Figura 1) è uno strumento di valutazione dell'infrastruttura a livello dell'intera rete, progettato per ottenere rapidamente una visione d'insieme di server e desktop e verificare se essi siano pronti per l'aggiornamento o per la migrazione a tecnologie come Hyper-V, Microsoft Application Virtualization, Windows Server 2008, Windows Vista, Office 2007 e SQL Server.
Figura 1 Toolkit Microsoft Assessment and Planning 3.1 (fare clic sull'immagine per ingrandirla)
Come si nota nella Figura 2, MAP genera automaticamente report di valutazione della prontezza e proposte, risparmiando all'utente molto lavoro. Toolkit MAP 3.1 supporta sia scenari server che desktop ed è in grado di analizzare i computer desktop in funzione dell'aggiornamento a Windows Vista e pianificare il rollout di Microsoft Application Virtualization.
Figura 2 Esempio di architettura di migrazione autogenerata (fare clic sull'immagine per ingrandirla)
Per la pianificazione della virtualizzazione server, sono tre le funzionalità principali dello strumento che aiutano a determinare i migliori candidati tra le diverse macchine fisiche: inventario dei server, raccolta di misurazioni sulle prestazioni e consigli sul posizionamento di virtualizzazione. È utile esaminare uno scenario concreto che illustri come utilizzare queste funzionalità per creare un'immagine dettagliata dell'ambiente esistente e pianificare il passaggio alla virtualizzazione.

Analisi della situazione
Molte grandi aziende hanno a disposizione qualche forma di infrastruttura di gestione server, ad esempio, System Center Operations Manager. Alcuni ambienti sono gestiti in modo meno attivo. Se si lavora in un ambiente di cui non si conoscono i server effettivamente a disposizione né i sistemi operativi utilizzati, la funzionalità Server Inventory (Inventario server) può contribuire a ottenere un quadro chiaro della situazione. Server Inventory (Inventario server) è in grado di individuare le macchine nell'ambiente utilizzando Active Directory, una scansione dell'intervallo di indirizzi IP o semplicemente importando un elenco di macchine da un file flat. Come illustrato dalla Figura 3, si possono utilizzare anche più metodi di rilevamento contemporaneamente (Active Directory e scansione degli indirizzi IP, ad esempio) per individuare le macchine che dovrebbero trovarsi nell'Active Directory ma non lo sono.
Figura 3 Scelta del metodo di rilevamento computer (fare clic sull'immagine per ingrandirla)
Una volta rilevate le macchine, Toolkit MAP 3.1 tenta di connettersi a ciascuna di esse e recuperare più di 50 classi di dati tramite Strumentazione gestione Windows (WMI). Sulla base di questi dati, possono essere generati vari tipi di report. Per il consolidamento dei server con la virtualizzazione, interessano maggiormente i report creati selezionando Migrate specific roles and services to Windows Server 2008 (Esegui migrazione di ruoli e servizi a Windows Server 2008).
Anche se la migrazione a Windows Server 2008 non deve essere effettuata immediatamente, i due report creati in questo scenario sono preziosi per determinare il tipo di hardware a disposizione nell'ambiente (inclusi tipo di processore e velocità, dimensioni del disco e memoria installata), nonché i ruoli software assegnati a ciascun server (server DNS, controller di dominio e Servizi terminal).
I report vengono forniti sotto forma di cartelle di lavoro Microsoft Excel, è quindi facile utilizzare gli strumenti di classificazione e filtro di Excel per identificare esattamente tra le macchine dell'ambiente i migliori candidati per la virtualizzazione.
I report dell'inventario dei server forniscono dati su diversi attributi di cui tenere conto nella scelta dei server da virtualizzare. Ad esempio, potrebbe essere necessario accertarsi che i computer virtualizzati eseguano un sistema operativo supportato dalla piattaforma di virtualizzazione Hyper-V. Nella cartella di lavoro di Excel WS2008HardwareAssessment creata dal processo di inventario dei server, nella scheda Server Inventory (Inventario server), si possono controllare le colonne Current Operating System (Sistema operativo corrente) e Service Pack per individuare i sistemi che necessitano di aggiornamento.

Determinazione degli utilizzi attuali
Il passaggio successivo per l'individuazione dei candidati per la virtualizzazione consiste nel misurare il grado di utilizzo delle macchine fisiche. La procedura guidata Performance Metrics (Valutazione delle prestazioni) di Toolkit MAP 3.1 (vedere Figura 4) registra i contatori di prestazioni da un elenco di macchine identificate come candidati per la virtualizzazione. Vengono acquisiti, per la successiva analisi, i dati sull'utilizzo di CPU, I/O del disco e rete.
Figura 4 Procedura guidata Performance Metrics (Valutazione delle prestazioni) (fare clic sull'immagine per ingrandirla)
Questa parte dello strumento è stata progettata per osservare i computer nell'arco di un periodo abbastanza lungo (fino a un mese), in modo da garantire una certa flessibilità nella scelta delle modalità di utilizzo. Se si ha già un'idea approssimativa dei momenti in cui nell'ambiente si verificano gli utilizzi più intensi (ad esempio, in corrispondenza di una finestra di elaborazione batch settimanale), è possibile impostare l'esecuzione della procedura guidata soltanto per alcune ore attorno a quel momento. Tuttavia, se non si è certi di quando si verifichino gli utilizzi più elevati, o se si desidera osservare molti computer con momenti diversi di utilizzo massimo, si può stabilire che la procedura guidata venga eseguita per diversi giorni o settimane al fine di registrare i dati dei computer. Questo consente allo strumento di identificare automaticamente i momenti di massimo utilizzo da una serie più estesa di dati.
Con le informazioni dell'inventario precedente, accedere alle funzionalità di classificazione e filtro in Excel per creare un elenco di computer da monitorare. La procedura guidata Performance Metrics (Valutazione delle prestazioni) accetterà questo elenco in formato file flat con un nome di computer per riga. Copiare l'elenco di nomi di computer da Excel in un nuovo file di testo vuoto nel Blocco Note, quindi salvarlo. Quando richiesto, importare il file salvato nella procedura guidata e impostare l'ora di fine del periodo di raccolta delle misurazioni sulle prestazioni. La procedura guidata passerà alla modalità di raccolta dati e registrerà i contatori di prestazioni dei computer specificati ogni cinque minuti.
Una volta completata la procedura guidata Performance Metrics (Valutazione delle prestazioni), verrà creato in Excel un report dettagliato che elenca tutte le macchine osservate e le misurazioni sulle prestazioni per le diverse categorie di utilizzo: CPU, disco fisico, disco logico e rete. Con queste informazioni, si può ulteriormente restringere l'elenco di candidati da tenere in considerazione per la virtualizzazione.
È possibile concentrarsi sui computer con utilizzi molto bassi e cercare di consolidarne diversi sotto forma di macchine virtuali (MV) su un unico host oppure combinare queste informazioni con i dati di inventario, in modo da individuare computer con servizi critici che necessitano di un'elevata disponibilità. La virtualizzazione può essere utilizzata per fornire funzionalità di ripristino di emergenza migliorate per gli ambienti ad elevata disponibilità. Dopo l'analisi, si può passare alla fase finale di creazione di consigli sul posizionamento di macchine virtuali.

Consigli sul posizionamento dei server
La procedura guidata Server Virtualization and Consolidation (Virtualizzazione e consolidamento server) consente di specificare la configurazione di un ipotetico computer host di virtualizzazione in termini di CPU, rete, sottosistema del disco e memoria. Utilizzando i dati sulle prestazioni raccolti dalla procedura guidata Performance Metrics (Valutazione delle prestazioni), la procedura guidata Server Virtualization and Consolidation (Virtualizzazione e consolidamento server) calcola un mapping significativo tra MV guest e MV host, garantendo che ogni host venga utilizzato correttamente senza rischiare un impiego eccessivo durante i periodi di massimo utilizzo.
Al termine della procedura Server Virtualization and Consolidation (Virtualizzazione e consolidamento server), viene prodotto un foglio di lavoro Excel dettagliato con la proposta di mapping tra MV guest e host fisici. Per ciascuna MV e per ciascun host, il report riporta i valori stimati di utilizzo di I/O del disco, I/O di rete e CPU. Mano a mano che le MV vengono aggiunte alle macchine che fungono da host fisici durante il processo di adattamento, vengono assegnati nuovi computer host via via che gli host precedenti raggiungono il limite di capacità. Per ogni nuovo host, viene visualizzato un messaggio che indica la ragione dell'aggiunta dello stesso.
Se per diversi host si ottiene lo stesso messaggio, può essere utile ripetere la procedura guidata di posizionamento con una configurazione host diversa, per tentare di aumentare il numero di guest assegnati a ciascun host. Se, ad esempio, per diversi host appare il messaggio di raggiungimento del limite di memoria, si può provare a ripetere la procedura guidata specificando una maggiore quantità di RAM per la configurazione degli host. In tal modo si dovrebbe aumentare il numero di guest che possono essere assegnati a ogni host.

Configurazione delle macchine virtuali
Ogni pagina della procedura guidata Server Virtualization and Consolidation (Virtualizzazione e consolidamento server) consente di configurare un componente principale della ipotetica configurazione di computer che sarà utilizzata per modellare la capacità del computer MV host. Sono forniti modelli sia per Virtual Server 2005 R2 che per Hyper-V e, nella prima pagina della procedura guidata, viene richiesto di indicare quale tecnologia di virtualizzazione si desidera utilizzare (vedere la Figura 5).
Figura 5 Scelta della tecnologia di virtualizzazione da utilizzare per i consigli sul posizionamento (fare clic sull'immagine per ingrandirla)
I modelli per diverse famiglie di CPU di AMD e Intel sono forniti nella pagina di configurazione della CPU. Se non è disponibile un modello per una CPU specifica, scegliere la corrispondenza più prossima. In questa pagina si può configurare il numero di processori fisici, core e hyper-thread per core. Si noti che, scegliendo Hyper-V come piattaforma di virtualizzazione, potranno essere scelte solo CPU a 64 bit (vedere la Figura 6).
Figura 6 Configurazione CPU host (fare clic sull'immagine per ingrandirla)
La terza pagina della procedura guidata consente di configurare un sottosistema del disco in termini di numero di unità del disco e tecnologia RAID per calcolare lo spazio su disco totale disponibile sull'host e un valore di velocità effettiva del sottosistema del disco. Il valore di produttività fornito è automaticamente basato sulla tecnologia di interfaccia e sulla velocità del disco Monitoraggio affidabilità e Performance Monitor (RPM).
Toolkit MAP 3.1 non offre il supporto diretto della modellazione di soluzioni disco di tipo rete di archiviazione (SAN) e Network Attached Storage (NAS). Per approssimazione, scegliere la tecnologia di disco SCSI e configurare un livello RAID simile alla configurazione SAN con dischi di velocità simile. Questa approssimazione dovrebbe essere abbastanza vicina da favorire la pianificazione iniziale.

Vincoli di posizionamento
Via via che i computer guest vengono associati agli host fisici, vengono presi in considerazione sei fattori per valutare se un guest potrà essere contenuto nella capacità residua di un computer host:
  • Utilizzo della CPU
  • Utilizzo I/O di rete
  • Utilizzo I/O sottosistema del disco
  • Memoria
  • Spazio su disco
  • Supporto del sistema operativo guest da parte della tecnologia di virtualizzazione specificata
L'utilizzo di CPU, rete e sottosistema del disco sono relativamente semplici. Gli utilizzi misurati sul candidato di virtualizzazione guest fisico vengono convertiti nell'utilizzo equivalente sul computer host di virtualizzazione e aggiunti all'utilizzo esistente dell'host. Se l'utilizzo totale risultante da tutti i guest assegnati all'host per la risorsa specifica è inferiore al limite soglia, il guest viene assegnato all'host. In caso contrario il guest non sarà posizionato e verranno presi in esame altri guest per individuarne uno più adatto.
Si supponga, ad esempio, di avere raccolto misurazioni di prestazioni di un computer con CPU Pentium 4 da 1,2 GHz con utilizzo della CPU del 32%. Se si configura un host di virtualizzazione con CPU Intel Xeon quad-core serie 5300, l'utilizzo della CPU originale misurato dal potenziale computer guest sarà estrapolato in un utilizzo equivalente stimato sul computer host. Il nuovo utilizzo sarà inferiore al valore originale misurato grazie a un'architettura di CPU più nuova, diversa velocità di clock della CPU e l'aggiunta di più core.
Se, al contrario, è stato configurato un computer host con CPU meno potente di quella del guest, l'utilizzo stimato sarà più elevato una volta estrapolato all'host. In entrambi i casi il nuovo utilizzo della CPU estrapolato sarà impiegato per calcolare l'utilizzo globale del computer host con il procedere delle assegnazioni.
Vale la pena illustrare brevemente la modalità con cui vengono prese decisioni sull'utilizzo di memoria e spazio su disco. La quantità totale di memoria fisica installata su ogni potenziale guest di virtualizzazione è riservata sul computer host. Inoltre, una piccola quantità di memoria (512 MB) è riservata per l'host stesso. Quando la memoria totale sull'host è esaurita a causa dell'assegnazione di guest, più l'overhead dell'host, non possono essere posizionati altri guest di virtualizzazione su quello specifico computer host.
Lo spazio su disco è gestito allo stesso modo: la quantità totale di spazio fisico su disco di ogni potenziale guest di virtualizzazione è riservata sul computer host. Inoltre, 50 GB di spazio su disco sono riservati per l'host di virtualizzazione. Quando l'utilizzo totale del disco di tutti i guest assegnati all'host, più lo spazio riservato all'host stesso, raggiunge le dimensioni specificate nella configurazione dell'host, non può più essere assegnato alcun guest aggiuntivo.
A seconda della piattaforma di virtualizzazione scelta, saranno effettuate verifiche per garantire che il sistema operativo eseguito sul computer guest sia effettivamente supportato dalla piattaforma di virtualizzazione. I sistemi operativi a 64 bit, ad esempio, non sono supportati come guest su Virtual Server 2005 R2, dunque non saranno posizionati se si sceglie questa tecnologia di virtualizzazione.

Valutazione delle opzioni
Eseguendo più volte la procedura guidata Server Virtualization and Consolidation (Virtualizzazione e consolidamento server), diventa semplice confrontare i risultati di scelte hardware diverse per il computer host di virtualizzazione. Ogni volta che si ripete la procedura guidata, si possono scegliere opzioni di CPU, di disco e di memoria differenti per individuare la soluzione migliore per il proprio ambiente.
Basta prestare attenzione alla colonna Last Placement Failed Reason (Motivo dell'ultimo posizionamento non riuscito) nella scheda Consolidation Recommendations (Consigli di consolidamento) della cartella di lavoro di Excel di consolidamento dei server. I motivi forniscono indizi sulla ragione per cui non è stato possibile posizionare su un host particolare più macchine guest. Se per diversi host è riportata la stessa ragione, ad esempio Memory utilization of guest exceeds available memory on host (L'utilizzo della memoria del guest supera la memoria disponibile sull'host), si può aumentare la quantità di memoria sulla configurazione dell'host per ridurre il numero totale di host necessari.

Requisiti
Uno dei vantaggi di Toolkit MAP 3.1 è che non richiede l'installazione di alcun software sui computer oggetto di inventario. Tutte le operazioni sono condotte in modalità remota. Tuttavia, affinché tutto funzioni correttamente, si devono tenere in considerazione alcuni fattori.
Perché le procedure guidate Inventory e Performance Metrics (Valutazione delle prestazioni) completino il lavoro, alcune porte TCP devono essere aperte sul computer di destinazione e accessibili dal computer su cui è installato Toolkit MAP. Nella Guida introduttiva si analizzano in dettaglio i requisiti; in breve, le porte per autenticazione, DCOM e WMI, devono essere aperte sui computer oggetto di inventario. Se sulla rete sono installati firewall tra il computer che esegue Toolkit MAP 3.1 e le destinazioni di inventario, tali firewall devono essere configurati per consentire il passaggio del traffico.
Toolkit MAP 3.1 è progettato per effettuare l'inventario di ambienti con un massimo di 100.000 computer e raccogliere i dati sulle prestazioni di un massimo di 3.000 computer per volta. Per impostazione predefinita, questo strumento installerà un'istanza privata di SQL Server 2005 Express Edition. A causa del limite di 4 GB sulle dimensioni dei file del database in SQL Server Express, questa configurazione consente l'inventario di soli 20.000 computer prima di raggiungere le dimensioni limite del file imposte da SQL Server Express. Per lavorare con più computer durante l'inventario, devono essere modificate alcune impostazioni predefinite.
Per lavorare in ambienti di maggiori dimensioni è necessario utilizzare una versione completa di SQL Server, ad esempio SQL Server 2005 Standard Edition. Prima di installare Toolkit MAP, installare un'istanza nuova di SQL Server 2005 e denominarla "MAPS". Eseguire quindi normalmente il programma di installazione di Toolkit MAP sullo stesso computer. Toolkit MAP richiede un'istanza locale di SQL Server: il programma di installazione rileverà automaticamente un'istanza "MAPS" locale del server di database ed effettuerà l'installazione in questa, anziché installare SQL Server Express Edition.
Per ambienti ancora più grandi, si può utilizzare la funzionalità di scalabilità orizzontale che consente a più computer helper, su cui sia installato Toolkit MAP, di eseguire insieme un grande inventario e memorizzare in cooperazione tutti i dati raccolti in un unico database centrale. Anche questa configurazione richiede l'uso di SQL Server Standard Edition per evitare il limite di 4 GB relativo alle dimensioni del file.
Per ulteriori informazioni su come installare lo strumento in questa configurazione e modificare correttamente le stringhe di connessione database per questa modalità, vedere la Guida introduttiva. La funzionalità di scalabilità orizzontale può essere anche utilizzata per installare SQL Server su un computer diverso da quello su cui è installato Toolkit MAP.

Conclusione
Gli acceleratori di soluzioni come Microsoft Assessment and Planning Toolkit sono tutti pensati per esonerare l'utente dalle attività più pesanti dei progetti IT. Toolkit MAP ha risparmiato a molti utenti diverse centinaia di ore di pianificazione informatica per distribuzioni Hyper-V. Se si ritiene di essere pronti a provarlo,
scaricare gratuitamente Microsoft Assessment and Planning Toolkit all'indirizzo microsoft.com/map o effettuare il download degli altri Virtualization Solution Accelerator da microsoft.com/vsa. È molto utile anche visitare il blog del team Toolkit MAP all'indirizzo blogs.technet.com/mapblog, per ottenere ulteriori suggerimenti e video di dimostrazione.

Jay Sauls è Senior Program Manager del gruppo Solution Accelerator presso Microsoft, dove ha lavorato a strumenti di progettazione e implementazione tra cui Windows Vista Hardware Assessment e Toolkit Microsoft Assessment and Planning. In precedenza, Jay ha lavorato in altri team di prodotto Microsoft, tra cui Microsoft Commerce Server, Microsoft BizTalk e System Center Capacity Planner.

Baldwin Ng è Senior Product Manager del team Microsoft Solution Accelerators Core Engineering. I suoi progetti attuali comprendono Microsoft Assessment and Planning Toolkit e Virtualization Solution Accelerators. Baldwin ha oltre 16 anni di esperienza nella gestione e nello sviluppo di prodotti per i settori informatica, e-commerce e servizi Internet wireless, raccolta presso Microsoft, Corbis e Alltel. Spesso scrive contributi su blogs.technet.com/MAPBLOG.


From the Editor È un mondo virtuale (virtualizzato)
Joshua Hoffman

La virtualizzazione non è cosa nuova. Questa affermazione (probabilmente non la più entusiastica per iniziare la nota di questo mese) è senza dubbio vera. Il concetto di virtualizzazione (separazione di un sistema operativo dalle risorse hardware sottostanti) esiste dal 1967, quando venne introdotto il sistema operativo IBM CP/CMS. Eppure, sebbene il concetto sia affermato, i cambiamenti negli ultimi 40 anni sono stati notevoli.
Nel 2008 è stato raggiunto il punto di non ritorno nella virtualizzazione dei computer. Con la convergenza su processori multicore più potenti e dotati della nuova tecnologia hypervisor per esigenze di riduzione dei costi, semplificazione della gestione e definizione di pratiche di computing sostenibili, la virtualizzazione è ora pronta ad assumere un ruolo da protagonista. Questo numero di TechNet Magazine è dedicato proprio alle nuove frontiere della virtualizzazione. All'interno della rivista sono stati raccolti articoli che descrivono la nuova e promettente piattaforma Hyper-V di Windows Server 2008, gli strumenti per gestire un ambiente virtuale, le tecniche per distribuire le applicazioni virtuali e molto altro ancora.
A un livello più personale, desidero esprimere un debito di gratitudine a nome dell'intero staff di TechNet Magazine ai collaboratori Greg Stemp e Jean Ross, appartenenti al famigerato gruppo dei "Microsoft Scripting Guy". So che può essere uno shock scoprire che i Microsoft Scripting Guy in realtà non sono ometti in camice da laboratorio con teste sproporzionate che corrono per i corridoi di Microsoft con una provetta in una mano e uno script nell'altra. Negli ultimi tre anni, Greg e Jean hanno curato la rubrica di TechNet Magazine "Hey, Scripting Guy!" ricevendo riconoscimenti in tutto il mondo. Hey, Scripting Guy!, oltre a essere diventata la rubrica più amata tra quelle pubblicate, ha vinto svariati premi e riceve più apprezzamenti e messaggi di posta elettronica dei lettori di quanti potremmo mai contare.
È per tutti questi motivi e per molti altri ancora (non da ultimo, il fatto che vogliamo loro molto bene) che l'addio a TechNet Magazine annunciato da Greg e Jean questo mese ci rattrista molto. Ahimè, come sempre succede ai migliori, Greg e Jean sono chiamati a pascoli più verdi. Per fortuna, continueranno a vagare per i corridoi di Redmond, dispensando il loro talento a beneficio dei clienti di Microsoft. Auguriamo a entrambi il meglio, con la speranza che, un giorno, le loro parole tornino ad arricchire le nostre pagine.
Nel frattempo, Dean Tsaltas, venerabile alunno degli Scripting Guy, ha gentilmente acconsentito a raccogliere la sfida e di occuparsi di Hey, Scripting Guy! nel periodo di transizione fino a quando non individueremo la prossima generazione di Scripting Guy. Dean si unirà a noi il mese prossimo per sondare le profondità di Windows Management Instrumentation. Da non perdere! —Joshua Hoffman

Si ringraziano i seguenti esperti tecnici Microsoft: Karri Alexion-Tiernan, Carmen Asher, Scott Culp, Steve Ekren, Trina Gorman, Michael Michael, Mike Mitchell, Michael Murgolo, Rob Polly, Dan Reger, Jez Sadler, Bill Scheidel, Bryon Surace e Jim Truher.


Letters La parola ai lettori

Gestione del database SQL
Complimenti per l'articolo "SQL Server: Suggerimenti per una manutenzione efficiente dei database" nel numero di agosto 2008 (disponibile all'indirizzo technet.microsoft.com/magazine/cc671165). Finalmente, un articolo nella sezione su SQL è stato indirizzato a noi "amministratori di database involontari", che dobbiamo assicurarci che l'applicazione SQL Server sia in esecuzione e che ne venga eseguito il backup.
Nella pagina seguente seguiva l'articolo "Windows Administration: Misurazione dei battiti del server" (technet.microsoft.com/magazine/cc718984): davvero eccezionale. Ho ritagliato questi articoli dalla rivista per conservarli: qualcosa che non si può fare con l'edizione digitale. Consulterò spesso entrambi gli articoli. Continuate così.
Siamo contenti che questi due articoli ti siano piaciuti, ci fa sempre piacere sapere che i nostri contenuti sono utili. Non rifiutiamo mai gli elogi, ma per favore non fermarti qui! Sentiti libero di scriverci, segnalando gli argomenti che vorresti che fossero trattati nei prossimi numeri. Siamo sempre alla ricerca di richieste da parte dei nostri lettori.
—Joshua Hoffman, caporedattore

Image X e Windows PE
Grazie per l'articolo su come distribuire i vecchi sistemi operativi con ImageX e Windows PE ("Avvio doppio con Windows XP e Windows PE 2.0" di febbraio 2008, technet.microsoft.com/magazine/cc194422). L'anno scorso ho scoperto il potenziale di questi strumenti e ho iniziato a sperimentarli, perché intendevo sostituire lo strumento di creazione delle immagini in uso nella mia azienda (Acronis Snap Deploy). Sei mesi fa sono riuscito a far funzionare tutto in base alle mie esigenze e ora è l'unico strumento di creazione di immagini che utilizziamo.
Poi ho letto l'articolo, in cui si consiglia l'aggiunta dell'opzione bootsect.exe /n52, di cui non avevo mai sentito parlare prima. L'unica operazione che eseguiamo prima dell'applicazione delle immagini è la cancellazione del disco rigido utilizzando DiskPart con lo script incluso (commands.txt). Per ora non si sono ancora verificati problemi, ma in futuro potrebbero presentarsi?
Inizialmente, questo comando era necessario. Tuttavia, dopo la pubblicazione dell'articolo in questione, un membro del team mi ha informato che non era più necessario, poiché il codice di avvio ora dispone della logica necessaria per cercare uno nuovo tipo di codice di Boot Manager e, nel caso non lo trovasse, tenta con NTLDR prima di restituire un errore. Quindi può essere del tutto omesso senza causare problemi.
—Wes Miller, Redattore, The Desktop Files

Ambiente di test per immagini
Ho letto l'articolo nella rubrica Desktop File che tratta l'implementazione delle immagini mediante lo strumento ImageX e l'abilitazione del multicast tramite i Servizi di distribuzione Windows (WDS, "Avvio doppio con Windows XP e Windows PE 2.0"). Vorrei preparare un ambiente di test e sapere esattamente quali sono gli strumenti necessari. Devo installare Windows Server 2008 per un'implementazione multicast? Inoltre, per le immagini mirror è necessario utilizzare ImageX per l'installazione della Distribuzione 4 o del Windows Automated Installation Kit (WAIK) e dei Servizi di distribuzione Windows?
Per utilizzare il multicast con WDS, è necessario aver installato Windows Server 2008, i componenti di multicast, infatti, non sono disponibili (e non lo saranno) per Windows Server 2003.
La Distribuzione 4 non è necessaria per l'utilizzo di multicast. Per utilizzarlo, sono richiesti Windows Server 2008 e la versione di WAIK rilasciata per Windows Server 2008, che è la prima versione a contenere i componenti necessari per il multicast in Windows PE.
—Wes Miller

Multicast in WDS
Ho tentato di utilizzare ImageX per clonare le immagini nei e dai computer, ma ho rilevato subito un problema: ImageX non supporta le trasmissioni multicast. Vorrei fare lo stesso utilizzando i server WDS con le trasmissioni multicast. È possibile? Sembra che il comando Wdsmcast possa risolvere il problema. In che modo il client WDS comunica al server WDS quale immagine scaricare?
In verità, ImageX non può gestire il multicast: si deve utilizzare Wdsmcast (nel WAIK di Windows Server 2008) per specificare a quale trasmissione connettersi (dopo averla avviata sul server). Il white paper relativo all'utilizzo del server di trasporto fornisce informazioni sulla modalità di connessione con Wdsmcast (technet.microsoft.com/library/cc725964). Leggi la sezione sulle modalità di connessione del server client a uno spazio dei nomi che utilizza Wdsmcast.exe.
—Wes Miller

Contattaci Desideri esprimere un commento? Inviaci un messaggio di posta elettronica all'indirizzo tnmag@microsoft.com o visita il nostro blog all'indirizzo blogs.technet.com/tnmag.


Toolbox Nuovi prodotti per professionisti IT
Greg Steen

Tutti i prezzi sono stati confermati il 19 agosto 2008 e sono soggetti a modifiche. Le opinioni espresse nella presente rubrica si riferiscono esclusivamente all'autore e non rispecchiano necessariamente le opinioni di Microsoft.

Porta con te le tue applicazioni
PortableApps.com
PortableApps.com
Essendo un professionista IT, è probabile che spesso ti capiti di spostarti da un computer all'altro. In tali occasioni probabilmente desideri avere sempre a portata di mano il tuo set standard di applicazioni, strumenti e documenti. Una soluzione interessante per esigenze di questo genere è rappresentata dall'utilizzo di una piattaforma di avvio come quella fornita da PortableApps.Com. All'interno del sito sono disponibili la piattaforma gratuita e open-source PortableApps.com e numerose applicazioni portatili che possono essere eseguite unicamente da un'unità memoria flash USB, una scheda di memoria, un disco rigido portatile o un lettore di musica digitale.
Esiste anche una suite di prodotti PortableApps.Com. Questo download è molto utile poiché contiene l'insieme delle applicazioni portatili disponibili insieme alla piattaforma di base, il tutto in un unico programma di installazione. La suite è disponibile in due versioni. La versione Light contiene Mozilla Firefox, Thunderbird e Sunbird con l'antivirus ClamWin, Pidgin per la messaggistica istantanea, il lettore di PDF Sumatra, il gestore di password KeePass, il programma di elaborazione testi AbiWord, un lettore audio e alcuni semplici giochi. Nella versione Standard, a queste applicazioni si aggiunge la suite di prodotti per l'ufficio OpenOffice.org, contenente Writer, Calc, Impress, Base e Draw.
Sono incluse inoltre altre applicazioni open source che sono state rese "portatili" sul sito, tra cui FileZilla per FTP, PuTTY per telnet e SSH, WinSCP per SFTP e SCP, PNotes e Task Coach per i comandi rapidi, 7-Zip per l'archiviazione, un prompt dei comandi, Eraser per cancellare file, InfraRecorder per masterizzare CD/DVD, WinDirStat per visualizzare il contenuto di un disco, winMd5Sum per la verifica dei file e WinMerge per le differenze di file e directory. (Chi legge assiduamente la mia rubrica Toolbox avrà notato che molte di queste applicazioni sono state descritte nei numeri precedenti).
Esiste anche una community di utenti molto attiva che sta lavorando alla versione portatile di utilità di rete come WinPCap e Wireshark. (Questi due strumenti possono essere davvero utili per le attività di amministrazione e di risoluzione dei problemi). I forum offrono un ambiente apposito per suggerire le applicazioni da rendere portatili.
Queste applicazioni funzionano in maniera indipendente nella periferica di archiviazione in uso. Se scrivono sul file di registro di sistema o richiedono qualsiasi accesso "off-disk", al momento dell'uscita tutto dovrebbe tornare allo stato precedente all'esecuzione. Le applicazioni possono essere eseguite senza la piattaforma PortableApps.Com: esse sono disponibili nei relativi programmi di installazione proprio per svolgere questa funzione. Tuttavia, probabilmente le funzionalità della piattaforma ti serviranno comunque e la suite è un ottimo punto di partenza dove iniziare a creare un ambiente personalizzato da portare sempre con te.
La piattaforma PortableApps.Com è predisposta per l'esecuzione automatica. Pertanto, inserendo l'unità di memoria flash USB o portatile nel computer host Windows, è possibile eseguire l'applicazione della piattaforma. Una volta avviata la piattaforma, viene visualizzata un'icona nella barra delle applicazioni. Facendo clic su questa icona, compare un menu simile al menu Start di Windows. Questa utilità di avvio dell'applicazione fornisce collegamenti rapidi a tutte le applicazioni portatili e alle cartelle di documenti sull'unità portatile, un indicatore dello spazio disponibile sull'unità, un'utilità di backup per i documenti sull'unità, uno strumento di ricerca e un collegamento per l'installazione di nuove applicazioni portatili. È possibile personalizzare questa interfaccia e scegliere una delle oltre 30 lingue disponibili.
Dopo aver acquisito familiarità con la piattaforma, potrebbe interessarti scoprire come modificare un'applicazione per renderla portatile. Per aiutarti a conoscere questo processo, il sito Web ospita anche un forum attivo dedicato allo sviluppo di applicazioni portatili. Considerando tutto ciò, si tratta proprio di un interessante set di strumenti in un pacchetto portatile.

Prezzo: gratuito.
Con PortableApps i tuoi strumenti sono sempre a portata di mano

Sistemi remoti per la risoluzione dei problemi
TeamViewer
teamviewer.com
Quando si cerca di risolvere problemi relativi ad un'applicazione tramite dimostrazioni del prodotto ed esercitazioni pratiche o semplicemente tentando di capire una domanda dell'utente, la cosa migliore da fare sarebbe proprio sedersi di fronte al computer in questione. Ma purtroppo spesso ciò non è possibile. La soluzione migliore per ovviare a questo problema è utilizzare uno strumento che aiuti ad "essere presente" senza esserlo realmente. TeamViewer di TeamViewer GmbH fa proprio questo.
Il processo di installazione di questa utilità è molto semplice e consente di connettersi a un computer remoto in maniera rapida. Le principali modalità operative supportate da TeamViewer sono quattro. Il Supporto Remoto, che consente di controllare il computer remoto, in modo da poter risolvere i problemi, fornire supporto nelle operazioni e nella manutenzione e guidare l'utente nello svolgimento di un'attività. La Presentazione, grazie alla quale è possibile visualizzare il desktop sul sistema dell'utente remoto e illustrare un'attività o fornire una presentazione. Il Trasferimento di file, che permette di trasferire file tra due computer senza la reale condivisione dei desktop. Infine, VPN che può creare una rete privata virtuale istantanea tra te ed il computer host (questa modalità utilizza l'opzione di installazione dell'adattatore VPN TeamViewer).
In termini di sicurezza, l'applicazione utilizza uno scambio di chiavi RSA e la codifica di sessione AES a 256 bit. Lo scambio di chiavi garantisce che nessun intruso (compresi i server di routing di TeamView) spii il flusso dei dati. Inoltre, al momento della connessione ad un Supporter (Supporter è il termine utilizzato per indicare colui che ospita una sessione) vengono generati un ID e una password di sessione che l'utente remoto deve inserire per connettersi. Nel caso in cui si desideri connettersi al computer di una postazione senza utente (ad esempio, per gestire i propri server), TeamViewer offre la funzione di installazione come servizio di sistema al fine di trasferire file con facilità, utilizzare le funzionalità di controllo remoto, creare un VPN o riavviare il computer remoto.
Un'altra funzionalità interessante, soprattutto se si intende utilizzare l'applicazione per fornire assistenza o effettuare presentazioni, è il modulo QuickSupport di TeamViewer (o il modulo Cliente). Si tratta di un eseguibile relativamente piccolo che non richiede installazione del software o diritti di installazione sul computer remoto da eseguire. L'utente finale deve semplicemente fare doppio clic sul file exe ed inserire l'ID e la password di sessione e potrà quindi connettere la propria sessione al computer.
TeamViewer presenta alcune opzioni di configurazione davvero utili. È possibile ottimizzare il numero di colori condivisi sul display, rimuovere lo sfondo dal display o scegliere di mantenere attivo Aero Glass di Windows Vista. Anche l'impostazione generale relativa a qualità/velocità delle sessioni può essere regolata. Si può anche decidere se consentire o meno l'attivazione delle diverse funzionalità, tra cui il controllo remoto, il trasferimento di file, le connessioni VPN, l'input di tastiera e mouse remoti, il controllo alternato di host locali e remoti e la visualizzazione della schermata remota.
Le sessioni possono essere registrate per essere visionate successivamente o per eseguire controlli in un secondo momento. E se non si desidera eseguire il routing attraverso i server di TeamViewer, magari a causa della propria configurazione di sicurezza, si può scegliere di impostare TeamViewer per l'utilizzo esclusivo di connessioni LAN per eseguire il routing da sé.
L'edizione Premium, che supporta installazioni illimitate di Supporter, contiene anche un'edizione portatile che può essere salvata su un CD o un'unità di memoria flash USB al fine di portare lo strumento con sé. L'edizione Premium contiene anche TeamViewer Manager, che registra i dettagli di sessione e consente di memorizzare i dettagli dei partner, due funzioni molto utili per la creazione di analisi, relazioni e fatture per i propri clienti. TeamViewer è disponibile anche per Mac OS X e supporta l'accesso multipiattaforma per connettersi a un Mac rimanendo sul proprio computer Windows.

Prezzo: Gratuito per l'utilizzo non commerciale. L'edizione aziendale è disponibile a partire da $699 per l'installazione di un Supporter. L'edizione Premium costa $1,399 e consente installazioni illimitate di Supporter.
Connessione a un sistema remoto con TeamViewer

Recensione
End-to-End Network Security: Defense-in-Depth
La protezione di rete comprende a tutt'oggi livelli multipli di tecnologie proattive per ridurre l'esposizione a incidenti e limitare le potenziali violazioni provenienti dall'interno e dall'esterno dell'infrastruttura di rete. End-to-End Network Security: Defense-in-Depth (Cisco Press 2007) di Omar Santos può aiutarti ad orientarti nella crescente complessità rappresentata dalla difesa della tua rete.
Sebbene questo libro per ragioni ovvie sia limitato alle apparecchiature Cisco, fornisce comunque numerose informazioni generali relative alla protezione e rappresenta un ottimo punto di riferimento per ogni professionista di rete o amministratore di sistema interessato alla sicurezza delle infrastrutture.
Il libro inizia con una panoramica sulle tecnologie di protezione di rete, da firewall e VPN ai sistemi prevenzione e rilevamento delle intrusioni e gestione delle identità. Segue la descrizione dettagliata di una metodologia in sei fasi per la gestione degli episodi di rischio per la sicurezza: preparazione, identificazione (dei rischi di protezione), classificazione (dei rischi di protezione), analisi, reazione e valutazione a posteriori.
Il testo continua esaminando un'infrastruttura di protezione proattiva che utilizza un'ampia gamma di periferiche e strumenti, tra cui ID/IP, NAC, AAA, SNMP, Syslog e VLAN. Segue la descrizione dell'approccio della difesa in profondità di Cisco che comprende reti wireless, telefonia IP, sicurezza centro dati e protezione IPV6 principalmente poiché esso riguarda le soluzioni offerte da Cisco in queste aree specifiche della protezione di rete. Il libro si conclude con tre casi di studio reali che illustrano le soluzioni di protezione adottate da piccole, medie e grandi imprese.

Prezzo: $49.50 (con acquisto diretto).

Ricerca ID dei dispositivi
PCIDatabase.com
PCIDatabase.com
Ti è capitato di aggiornare il sistema finendo per avere una o due periferiche sconosciute la cui descrizione indica soltanto "Periferica PCI" e non hai idea di come ottenere un driver o scoprire il tipo di periferica senza rimuovere il coperchio del tuo computer e dare un'occhiata all'interno? Oppure hai tentato di scoprire il tipo di chipset sottostante in una periferica nota. Un servizio gratuito che può aiutarti è PCIDatabase.com.
Questo database supportato dagli utenti ti consente di ottenere ulteriori informazioni effettuando una ricerca per nomi di fornitori e di periferiche e ID. Aprire Gestione periferiche, fare clic con il tasto destro sulla periferica in questione e selezionare Proprietà, scegliere la scheda Dettagli e poi selezionare la proprietà ID hardware. All'interno si trova una serie di stringhe che contengono pochi valori esadecimali preceduti da "VEN_" (per il fornitore) e "DEV_" (per la periferica).
Il sito fornisce collegamenti a molte risorse utili per aiutarti a scoprire se esistono driver disponibili per la periferica che hai cercato (non dimenticare di controllare anche sul sito Web del produttore).
Un'altra funzionalità interessante disponibile su PCIDatabase.com: se cerci un fornitore in particolare, viene visualizzata una pagina che include sede centrale, indirizzo, numeri di telefono, siti Web applicabili, contatti, ID esadecimale del fornitore per le periferiche PCI e una lista di tutte le periferiche del fornitore presenti nel sito. E poiché il sito è supportato dagli utenti, sei anche invitato ad aggiungere la tua opinione.

Prezzo: gratuito.
Ricerca di informazioni su fornitori e periferiche attraverso PCIDatabase.com (Fare clic sull'immagine per ingrandirla)

Risorse di controllo e inventario
CCS Network Inventory
crowcanyon.com
Scoprire che cosa è installato su uno dei tuoi computer client senza muoverti dalla tua scrivania consente di risparmiare molto tempo. E tenere traccia di queste risorse nel tempo fa parte del tuo lavoro. I sistemi Crow Canyon possono aiutarti a svolgere queste operazioni tramite la soluzione CSS Network Inventory.
Questa applicazione è uno strumento di inventario e controllo senza agente che esegue la scansione della LAN per le workstation, raccogliendo informazioni su hardware, software, servizi e utente. Poiché CSS Network Inventory non utilizza un agente remoto, il contesto di esecuzione necessita di RPC, servizio browser di computer, servizio di registro remoto, condivisione di file e stampanti e accesso condiviso ADMIN$ ai computer che si desidera sottoporre ad inventario (proprio come la maggior parte degli altri prodotti di inventario senza agente).
L'applicazione permette di utilizzare credenziali alternative per le query, un vantaggio quando la scansione si estende a domini multipli. Dopo aver installato l'applicazione, puoi eseguire la scansione di una gamma di indirizzi IP, utilizzare il rilevamento rete Windows, importare un elenco di computer o specificare manualmente un elenco di workstation di Windows da sottoporre a inventario.
In termini di controllo, CCS Network Inventory raccoglie i dettagli software seguenti: le applicazioni installate, gli aggiornamenti rapidi applicati, il sistema operativo e il Service Pack installati sul computer e i font presenti. In termini di configurazione del computer, sono visualizzabili i servizi e gli altri processi in esecuzione, le cartelle condivise, i mapping di unità, le variabili di ambiente, gli account utente, le attività pianificate, i comandi di avvio e i protocolli di rete attivi. E per quanto riguarda l'hardware, si possono visualizzare i dettagli di monitor collegati, stampanti, dischi rigidi (con dimensione e partizioni), informazioni su unità CD e DVD, processori, memoria e così via. Inoltre, si possono impostare scansioni personalizzate per i valori di registro, conteggi di file (ad esempio, chi possiede il maggior numero di mp3) e lo spazio disponibile sulle unità.
Tutte queste informazioni sono memorizzate nel database personalizzato dell'applicazione e i dati possono essere utilizzati in seguito per creare report. CCS Network Inventory fornisce un numero di report incorporati per visualizzare e spostare i dati al fine di eseguire controlli e preparare relazioni. Se i report incorporati e le informazioni di query non contengono esattamente ciò di cui si ha bisogno, si può utilizzare lo strumento incorporato SQL Query Builder che consente di scrivere ed eseguire query più dettagliate e specifiche all'interno dei dati.
Nel corso del tempo è buona norma acquisire snapshots dell'ambiente per rendersi conto dei cambiamenti avvenuti. Con CSS Network Inventory questi cambiamenti sono visibili confrontando due istanze dei database di informazioni. Ad esempio si possono paragonare la scansione attuale e una scansione eseguita l'anno precedente per determinare quante workstation sono passate a Windows Vista, in quante workstation i componenti hardware sono stati aggiornati nel corso dell'ultimo anno o quali utenti hanno continuato ad eseguire software non supportati dopo essere stati avvisati.
Al momento CSS Network Inventory non supporta completamente Windows 2008 Server, ma supporta le altre versioni di Windows fino a Windows Vista.

Prezzo: A partire da $235 fino a 25 nodi.
Gestione delle risorse remote con CSS Network Inventory.

Scrivi a Toolbox Se possiedi uno strumento o un'utilità che vorresti vedere recensiti qui, scrivi all'autore all'indirizzo tntools@microsoft.com.

Greg Steen è un professionista IT, un imprenditore e un entusiasta. È sempre alla ricerca di nuovi strumenti che aiutino a rendere più semplici le operazioni, il controllo della qualità e lo sviluppo per i professionisti IT.


SQL Q&A Log delle transazioni di grandi dimensioni, utilizzo della funzione Repair e molto altro ancora
Paul S. Randal

D Ho riscontrato un'anomalia nei backup che spero tu possa spiegarmi. Di tanto in tanto, eseguiamo il backup del nostro database di produzione da 62 GB per aggiornare i dati utilizzati dagli sviluppatori di applicazioni. Eliminiamo sempre la vecchia copia prima di ripristinare la nuova. La copia ripristinata ha le stesse dimensioni del database di produzione e i dati sono uguali, ma il processo di ripristino dura molto più a lungo rispetto a quello di backup. Quale può essere la causa? Perché è necessario più tempo per eseguire il ripristino rispetto al backup?
R In realtà non sta accadendo niente di strano: a seconda delle circostanze, si tratta in generale di un comportamento previsto. La differenza tra il tempo necessario per il backup e quello necessario per il ripristino deriva dai passaggi che ogni processo deve eseguire.
Il processo di backup di database prevede due passaggi: in sostanza, si leggono gli I/O sul database, che poi vengono scritti sulla periferica di backup.
Passaggio 1: leggere tutti i dati allocati nei file di dati e scriverli sulla periferica di backup.
Passaggio 2: leggere parte del log delle transazioni e scriverla sulle periferiche di backup.
La quantità esatta di log delle transazioni necessaria può variare notevolmente, ma è tale quantità che permette il ripristino del database in un momento preciso (una spiegazione più approfondita è disponibile nel post del blog disponibile all'indirizzo sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx).
Il ripristino del database, invece, può comportare fino a quattro passaggi e le attività necessarie sono più complesse rispetto al semplice processo di lettura e scrittura di I/O.
Passaggio 1: se i file del database non esistono, crearli.
Passaggio 2: leggere tutti i dati e il log delle transazioni dal backup e scriverli nei relativi file del database.
Passaggio 3: eseguire la fase di rollforward del ripristino sul log delle transazioni.
Passaggio 4: eseguire la fase di rollback del ripristino sul log delle transazioni.
Il tempo totale necessario a eseguire entrambi i passaggi del processo di backup è approssimativamente lo stesso tempo necessario per il passaggio 2 del processo di ripristino (presupponendo che l'hardware sia simile e il server non stia eseguendo alcuna attività degli utenti). Il passaggio 1 del processo di ripristino può richiedere molto tempo se i file di dati sono di grandi dimensioni e devono essere inizializzati a zero (comportamento tipico in SQL Server 2000 e predefinito in SQL Server 2005).
Per evitare che questo accada, non eliminare i file esistenti prima di avviare il ripristino oppure, in alternativa, attivare l'inizializzazione immediata, in modo che i file vengano creati rapidamente (ulteriori informazioni sono disponibili all'indirizzo msdn.microsoft.com/library/ms175935.aspx).
Nei passaggi fasi 3 e 4 viene eseguito il ripristino sul database già ripristinato per renderlo coerente a livello di transazione: si tratta dello stesso processo a cui viene sottoposto il database durante il ripristino in caso di arresto anomalo. La durata del ripristino dipende dalla quantità di log delle transazioni che deve essere elaborata. Se al momento del backup, ad esempio, è attiva una transazione a esecuzione prolungata, tutto il log della transazione in questione sarà inserito nel backup e dovrà essere sottoposto a rollback.

D Sono indeciso tra la distribuzione dei log e il mirroring del database per ottenere una copia ridondante del nostro database di produzione. Mi preoccupa la quantità di log delle transazioni che dovranno essere scambiati tra i server, soprattutto per le operazioni di ricostruzione degli indici che vengono effettuate ogni notte. Ho sentito che il mirroring invia i comandi correnti di ricostruzione anziché il log delle transazioni e le ricostruzioni vengono effettuate sul mirror. È vero? Questo renderebbe il mirroring una soluzione più conveniente anche rispetto alla distribuzione dei log con il modello di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED), giusto?
R Ciò che hai sentito non è vero. Il mirroring del database funziona inviando i record correnti del log delle transazioni dal database principale al server mirror, dove vengono "riprodotti" nel database mirror. Non viene effettuata alcuna conversione o filtraggio, né alcun tipo di intercettazione di comandi T-SQL per il database sottoposto a mirroring.
Il mirroring del database supporta solo il modello di recupero con registrazione completa (FULL), quindi l'operazione di ricostruzione di indici verrà sempre registrata completamente. In base alla dimensione degli indici in questione, può essere generata una quantità significativa di log delle transazioni e, di conseguenza, un file di registro di grandi dimensioni sul database principale, con la conseguente occupazione di una notevole larghezza di banda per l'invio dei record del log al mirror.
Il mirroring del database può essere considerato come la distribuzione dei log in tempo reale (questo era, infatti, il nome utilizzato per la funzionalità durante le prime fasi di sviluppo di SQL Server 2005). Nella distribuzione dei log, i backup del log delle transazioni del database primario vengono regolarmente distribuiti al server secondario e ripristinati sul database secondario.
La distribuzione dei log supporta il modello di recupero con registrazione completa (FULL) e con registrazione minima delle transazioni di massa (BULK_LOGGED). Per un'operazione di ricostruzione di indici nel database sottoposto a distribuzione del log attraverso il modello di recupero con registrazione completa (FULL), verrà generata la stessa quantità di log delle transazioni di un database sottoposto a mirroring. Tuttavia, nel caso di un database sottoposto a distribuzione del log, i dati vengono inviati al database ridondante in un backup del registro (o una serie di backup del registro) e non sotto forma di flusso continuo.
Se il modello di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED) viene utilizzato nel database sottoposto a distribuzione del log durante la ricostruzione degli indici, sarà generata solo una quantità minima di log delle transazioni. Tuttavia, il successivo backup del log delle transazioni conterrà anche tutti gli extent dei file di dati modificati dall'operazione, sottoposta a registrazione minima, di ricostruzione degli indici. Quindi, i backup di log che comprendono la ricostruzione degli indici nel modello di recupero con registrazione minima delle transazioni di massa (BULK_LOGGED) avranno quasi le stesse dimensioni di quelli che prevedono la ricostruzione nel modello di recupero con registrazione completa (FULL).
Dunque la quantità di informazioni che deve essere inviata al database ridondante per la ricostruzione di un indice è quasi la stessa, sia nel caso di un database sottoposto a mirroring che di uno sottoposto a distribuzione dei log. Le due soluzioni differiscono per le modalità di invio delle informazioni: in modo continuativo o in batch.
Nella scelta tra questi due approcci, si devono considerare molti altri fattori (e sono così tanti da non poter essere discussi in un unico numero di SQL Q&A). Prima di prendere una decisione, si devono valutare tali fattori in base alle proprie esigenze (come il limite accettabile di perdita di dati e i tempi di inattività ammissibili).

D Utilizzo SQL Server 2005 e il log delle transazioni di uno dei database continua ad aumentare di dimensioni. Il database è impostato sulla modalità di ripristino completa ed eseguo i backup del log delle transazioni. Credevo che questa operazione avrebbe evitato l'aumento delle dimensioni del log. Cos'è che non funziona in questo processo?
R Hai ragione a considerare fondamentale l'esecuzione di backup del log delle transazioni in modalità di ripristino completa. Tuttavia, esistono altri fattori che possono contribuire all'aumento di dimensioni del log delle transazioni. Tutto dipende da ciò che il log delle transazioni richiede come necessario (o attivo). Altre probabili cause del problema, oltre alla mancanza di backup del log delle transazioni, includono replica, mirroring del database e la presenza di una transazione attiva.
La replica opera in modo asincrono, leggendo i record del log delle transazioni e caricando quindi le transazioni da replicare in un database di distribuzione separato. I record del log delle transazioni non ancora letti dal programma di lettura del log di replica non possono essere liberati. Se il carico di lavoro genera molti record del log delle transazioni ed è stato impostato un ampio intervallo di lettura del log di replica, i record si accumulano e causano l'aumento di dimensioni del log delle transazioni.
Se si esegue il mirroring asincrono del database, può verificarsi un backlog dei record del log delle transazioni non inviati dal server principale al server mirror (la cosiddetta coda di invio del mirroring del database). I record del log delle transazioni non possono essere liberati finché non vengono inviati correttamente. Con un elevato tasso di generazione di record di log delle transazioni e una larghezza di banda limitata (o altri problemi di hardware), il backlog si ingrandisce e causa l'aumento di dimensioni del log delle transazioni.
Infine, se l'utente avvia una transazione esplicita (ad esempio, utilizzando l'istruzione BEGIN TRAN) e, in seguito, esegue modifiche di qualsiasi tipo (ad esempio, l'istruzione DDL o un'operazione di inserimento/aggiornamento/eliminazione), i record del log delle transazioni generati devono essere conservati finché l'utente non esegue il commit o il rollback della transazione. Neppure i successivi record del log delle transazioni generati da altre transazioni possono essere liberati, poiché il log non può essere liberato selettivamente. Se un utente, ad esempio, non completa la transazione, il log delle transazioni continuerà a ingrandirsi man mano che nuovi record vengono generati senza poter essere liberati.
Per capire il motivo per cui il log delle transazioni non può essere liberato, è sufficiente eseguire una query nella vista del catalogo di sistema sys.database ed esaminare la colonna log_reuse_wait_desc, come nell'esempio seguente:
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
Se la causa è una transazione attiva, si può utilizzare l'istruzione DBCC OPENTRAN per ottenere ulteriori informazioni sulla transazione:
DBCC OPENTRAN ('dbname')

D Ho sentito dire che REPAIR_ALLOW_DATA_LOSS deve essere utilizzato solo come ultima risorsa per il ripristino in caso di danneggiamento, poiché è preferibile l'utilizzo di un backup. Per quale motivo il comando "repair per SQL Server 2005" non deve essere utilizzato e perché viene inserito nel prodotto nonostante sia così "pericoloso"?
R Innanzitutto, sono stato io a scrivere il comando repair per SQL Server 2005. Il problema di REPAIR_ALLOW_DATA_LOSS (che d'ora in poi chiamerò semplicemente Repair) è che il suo funzionamento non è chiaro. Il nome dell'opzione è stato scelto per sottolineare che l'esecuzione può causare la perdita di dati del database. La funzionalità di solito ripristina una struttura danneggiata del database eliminandola e, in seguito, correggendo tutto ciò che nel database si riferiva ad essa. Repair deve essere considerato l'ultima risorsa per rendere il database coerente dal punto di vista strutturale e non deve essere inteso come un mezzo per il salvataggio dei dati degli utenti. Il comando non eccede nell'eliminazione di dati, ma neppure nel salvataggio.
Può sembrare un modo irresponsabile di risolvere i problemi, ma quando è necessario eseguire un ripristino, si rivela il metodo più veloce e affidabile per riparare i danni. La rapidità è di fondamentale importanza in caso di ripristino di emergenza e la correttezza è assolutamente necessaria. È quasi impossibile progettare algoritmi di ripristino più complessi che funzionino rapidamente e correttamente in tutti i casi. Nel codice di ripristino esistono alcuni algoritmi complessi per la soluzione del caso in cui due indici abbiano la stessa pagina o lo stesso extent allocati, ma principalmente l'algoritmo è di ripristino e correzione.
Tuttavia, è opportuno tenere presenti alcuni aspetti del comando Repair.
  • Quando elimina le strutture danneggiate, Repair non considera i vincoli delle chiavi esterne, dunque potrebbe eliminare record da una tabella con una relazione di chiave esterna con un'altra tabella. È possibile determinare se si è verificato questo caso solo eseguendo il comando DBCC CHECKCONSTRAINTS dopo il ripristino.
  • Repair non considera (e non può considerare) alcuna logica aziendale intrinseca, né relazioni tra dati definite a livello di applicazione che possono venir meno in seguito all'eliminazione di dati. Anche in questa eventualità, determinare quanto accaduto è possibile solo eseguendo una qualsiasi verifica della coerenza personalizzata incorporata nell'applicazione.
  • Alcune operazioni di ripristino non possono essere replicate. Quando si esegue il comando Repair su un server di pubblicazione o su un nodo di una topologia peer-to-peer, possono verificarsi incongruenze all'interno della topologia, che dovranno essere corrette manualmente.
Per queste ragioni, in caso di danneggiamento è sempre consigliabile utilizzare un backup piuttosto che eseguire il comando Repair. Tuttavia, il comando è disponibile nel prodotto per l'eventualità in cui il database sia danneggiato, non esista un backup e sia necessario rimettere in linea il database rapidamente.

D Ho iniziato da poco a lavorare in una nuova azienda come amministratore di database e mi è stata assegnata la responsabilità di alcune applicazioni e dei relativi database di back-end. Le prestazioni di una delle applicazioni sono scadenti durante gli aggiornamenti. Approfondendo la questione, ho scoperto che ognuna delle tabelle utilizzate dall'applicazione ha un numero enorme di indici. Dopo aver chiesto informazioni, ho appreso che il precedente amministratore di database aveva l'abitudine di aggiungere un indice a ogni colonna della tabella, più alcune combinazioni. Non credo che siano necessari tutti quegli indici: come posso sapere quali eliminare senza correre rischi? In azienda si utilizza SQL Server 2005.
R Effettivamente, l'elevato numero di indici influisce in modo significativo sul calo delle prestazioni. A ogni inserimento, aggiornamento o eliminazione di una riga nella tabella, le operazioni corrispondenti devono essere effettuate in ogni indice non raggruppato. In questo modo si aggiunge un overhead in termini di I/O, utilizzo della CPU e generazione di log delle transazioni.
In SQL Server 2000 si poteva determinare quali indici fossero in uso solo mediante il profiling e l'esame dei piani di query. In SQL Server 2005 è disponibile una nuova vista a gestione dinamica (DMV) che registra l'utilizzo degli indici: sys.dm_db_index_usage_stats.
Questa DMV registra ogni utilizzo di ciascun indice (e la modalità con cui viene utilizzato) da quando il database di cui fa parte è stato creato. Le statistiche per tutti i database vanno perse quando si chiude SQL Server, mentre quelle relative a un singolo database sono eliminate quando quest'ultimo viene chiuso o scollegato. L'idea di base è che, se non viene visualizzato nell'output, un indice non è stato utilizzato da quando il database è stato avviato.
Un semplice approccio alla registrazione dell'utilizzo degli indici nel tempo consiste nell'eseguire periodicamente snapshot dell'output della DMV per poi confrontarli. Un elemento di cui molti non tengono conto è la necessità di tenere traccia dell'utilizzo degli indici sull'intero ciclo aziendale. Se si eseguisse uno snapshot per un unico giorno, ad esempio, si potrebbe notare che molti indici non vengono utilizzati. Ma se vengono utilizzati, ad esempio per velocizzare l'esecuzione dei report di fine mese, questi indici probabilmente non devono essere rimossi. Se un indice non è stato utilizzato per un intero ciclo aziendale, invece, probabilmente è possibile eliminarlo, recuperando spazio e ottimizzando le prestazioni.
Per ottenere del semplice codice da utilizzare per eseguire snapshot periodici della DMV, consulta il post sul mio blog all'indirizzo sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx.

Paul S. Randal è Managing Director di SQLskills.com e MVP per SQL Server. Paul ha scritto il comando DBCC CHECKDB/repair per SQL Server 2005 ed è stato responsabile di Core Storage Engine durante lo sviluppo di SQL Server 2008. Paul, che vanta una notevole esperienza nell'ambito del ripristino di emergenza, della disponibilità elevata e della gestione dei database, partecipa regolarmente a conferenze in qualità di relatore. Il suo blog è disponibile in SQLskills.com/blogs/paul.


Utility Spotlight Strumento di manutenzione delle macchine virtuali non in linea
Peter Skjøtt Larsen e Suveen Kumar Reddy Vuppala

Indice
L'Incubo della sicurezza
Dietro le quinte
Infrastruttura di manutenzione
Utilizzo dello strumento
Presto disponibile
Virtualizzare il carico di lavoro di un computer significa semplicemente utilizzare una macchina virtuale (VM) per alleggerire l'hardware sottostante spostando il carico di lavoro. I moderni reparti IT considerano le VM uno strumento utile in molte circostanze, tra cui:
Spostamento dei carichi di lavoro E' possibile utilizzare le VM per aumentare o ridurre con facilità la larghezza di banda del carico di lavoro di installazioni multiple secondo necessità, senza dover apportare modifiche all'hardware.
Sviluppo e test delle applicazioni E' possibile creare VM multiple che rappresentano ogni configurazione che un'applicazione è in grado di supportare senza la necessità di un hardware specifico.
Aggiornamenti del software E' possibile utilizzare le VM per mettere in linea la versione più recente di un software rendendo non in linea la versione precedente, il tutto sullo stesso hardware.
Distribuzione del software Le VM possono essere utilizzate come unità di distribuzione per un'applicazione line-of-business che presenta una combinazione di software coerente in un pacchetto pre-testato.

L'incubo della sicurezza
Uno dei vantaggi dell'utilizzo delle VM è la possibilità di memorizzarle non in linea come immagini VM. Successivamente, in caso di necessità, è possibile "svegliare" tali VM e distribuirle molto più rapidamente di quanto è possibile fare con l'hardware corrispondente.
Tuttavia, tenere non in linea un numero crescente di ambienti informatici rappresenta una sfida in termini di manutenzione. Per essere in linea, molti meccanismi di aggiornamento software si affidano a sistemi che permettono di verificare la presenza di aggiornamenti o di ricevere aggiornamenti in maniera automatica.
Se una VM non è in linea, è semplicemente un file presente sul computer e pertanto non può interagire con nessun meccanismo di aggiornamento. Una VM messa in linea dopo una pausa di alcuni mesi potrebbe diventare una minaccia per la rete, o la rete stessa potrebbe diventare una minaccia per la VM.
Non si tratta soltanto di perdere alcuni aggiornamenti del sistema operativo. Le applicazioni non aggiornate e i profili dei virus possono rendere le VM vulnerabili o non conformi agli standard aziendali.
Per aiutare i clienti a mantenere aggiornate le VM non in linea, il team di Microsoft Solution Accelerator ha creato lo Strumento di manutenzione delle macchine virtuali non in linea. Questo strumento è compatibile con System Center Configuration Manager (SCCM) 2007, Windows Server Update Services (WSUS) 3.0 e System Center Virtual Machine Manager (VMM) 2007 e permette di gestire l'aggiornamento delle VM memorizzate. La figura 1 illustra un rendering concettuale dello strumento e delle modalità in cui interagisce con i vari componenti esterni.
Figura 1 Funzionamento dello Strumento di manutenzione delle macchine virtuali non in linea (Fare clic sull'immagine per ingrandirla)
Al fine di rendere le VM disponibili per eventuali aggiornamenti, lo strumento utilizza VMM per distribuirle temporaneamente negli host di manutenzione. Poiché la configurazione di un host di manutenzione presenta in genere la CPU e la memoria necessarie per avviare contemporaneamente VM multiple, lo strumento può gestire le VM in gruppi.
Non appena le VM sono attive sugli host di manutenzione, SCCM o WSUS possono fornire loro gli aggiornamenti necessari. Dopo aver applicato gli aggiornamenti, lo strumento utilizza VMM per riportare le VM allo stato non in linea. (Nota: lo strumento supporta soltanto le VM gestite da VMM).

Dietro le quinte
Lo Strumento di manutenzione delle macchine virtuali non in linea utilizza Windows Workflow Foundation (WF) per gestire il processo di aggiornamento delle VM. Il processo prevede alcune decisioni: si inizia infatti scegliendo il corretto sistema di gestione degli aggiornamenti e selezionando l'host di manutenzione disponibile adatto alla VM, ci si accerta quindi che gli aggiornamenti siano stati effettuati ed infine ci si occupa delle eccezioni.
Grazie all'utilizzo di una soluzione Windows basata su WF il team di sviluppo ha beneficiato di una grande flessibilità per la modifica e lo sviluppo del processo. Offre inoltre una soluzione efficiente che può essere personalizzata in base alle specifiche esigenze degli utenti; nei frangenti critici di un processo la personalizzazione è possibile grazie a passaggi integrati pre/post flusso di lavoro.
Lo strumento utilizza Windows PowerShell per implementare singole attività sotto il livello del flusso di lavoro, integrandosi perfettamente con Windows PowerShell API offerto da VMM. E l'interfaccia utente basata su Microsoft .NET è simile ad un prodotto System Center, così i nuovi utenti possono lavorare in un ambiente familiare.

Infrastruttura di manutenzione
Una delle principali caratteristiche dell'infrastruttura di manutenzione è la configurazione della protezione di rete affinché le VM non vengano danneggiate durante il processo di aggiornamento. Nella versione 1.0 ciò è possibile grazie all'utilizzo di una rete privata virtuale (VPN) a cui si connettono sia VMM che il sistema di aggiornamento appropriato (WSUS o SCCM). L'infrastruttura più adatta ad una libreria VMM è una rete di archiviazione (SAN) connessa mediante Fibre Channel, che permette il trasferimento rapido di immagini VM agli host di manutenzione.
Tutte le VM devono far parte dello stesso dominio, un dominio che utilizza Active Directory e DNS. E' possibile dedicare server separati a VMM, WSUS, SCCM e alla libreria VMM, ma è possibile utilizzare anche combinazioni di server virtuali per ambienti più piccoli. Ovviamente, gli host di manutenzione devono essere server fisici.

Utilizzo dello strumento
Dopo aver impostato l'infrastruttura di manutenzione e prima di avviare lo strumento, occorre verificare che determinate impostazioni siano corrette. Assicurarsi che VMM gestisca tutte le VM appropriate, che il client di aggiornamento adeguato per ogni VM sia installato e che i pacchetti di aggiornamento necessari siano configurati in WSUS o SCCM. Accertarsi che i gruppi di host di manutenzione siano configurati in VMM è un'operazione facoltativa.
Quando si è pronti, avviare lo Strumento di manutenzione delle macchine virtuali non in linea che presenta numerosi passaggi di configurazione. È necessario assegnare il server VMM e il server WSUS o SCCM appropriati e poi indicare quale gruppo di host di manutenzione (se gli host di manutenzione sono raggruppati) e quali host di manutenzione del gruppo vanno utilizzati (vedere la Figura 2). E' possibile configurare i gruppi di VM da gestire, ma tale operazione è facoltativa.
Figura 2 Configurazione dello Strumento di manutenzione delle macchine virtuali non in linea (Fare clic sull'immagine per ingrandirla)
Dopo aver configurato lo strumento, creare i processi di manutenzione. Un processo di manutenzione contiene tutte le informazioni che lo strumento utilizza per gestire le singole VM, compreso l'utilizzo di WSUS o SCCM per gli aggiornamenti; le posizioni del server VMM e del server WSUS o SCCM; le identità delle VM da gestire; il tipo (o l'identità, a seconda dei casi) della rete da utilizzare per il processo; le identità degli host di manutenzione da utilizzare; le credenziali di un account necessarie per accedere alle VM, al server VMM, al server WSUS o SCCM; infine, l'elenco dei passaggi per eseguire il processo di manutenzione (esecuzione immediata o in una data e ad un'ora specifiche).
Se si specifica una data e un'ora per il processo di manutenzione, Windows Task Scheduler determina quando avviarlo. Durante l'esecuzione del processo di manutenzione, lo Strumento di manutenzione delle macchine virtuali non in linea segue questa sequenza per ogni VM:
  • Sceglie la VM successiva dalla libreria VMM.
  • Interroga VMM sull'host di manutenzione più appropriato.
  • Installa la VM nell'host di manutenzione.
  • Si accerta che la VM si connetta alla rete corretta.
  • Avvia la VM.
  • Si assicura che sulla VM sia installato il client di aggiornamento corretto.
  • Avvia il processo di aggiornamento.
  • Attende che il processo di aggiornamento sia completo.
  • Arresta la VM.
  • Memorizza nuovamente la VM nella libreria VMM.
Il tempo necessario all'aggiornamento di una libreria VM può variare considerevolmente, in base al numero e alla capacità degli host di manutenzione, alla velocità di accesso alla libreria VMM e alla natura degli aggiornamenti.
Occorre notare che la versione attuale (1.0) dello Strumento di manutenzione delle macchine virtuali non in linea non supporta la protezione accesso alla rete (NAP), uno dei metodi migliori per proteggere le VM dalla rete. Inoltre lo strumento non supporta la tecnologia Hyper-V di Windows Server 2008 e non utilizza Windows Server 2008 come sistema operativo del client.
Le versioni più recenti di SCCM, WSUS e VMM saranno disponibili prossimamente e la versione 2.0 dello Strumento di manutenzione delle macchine virtuali non in linea supporterà tutte queste tecnologie, compresi Hyper-V e Windows Server 2008 per l'utilizzo sul client. Lo strumento supporterà anche la protezione accesso alla rete per l'isolamento della rete. E' possibile scaricare lo Strumento di manutenzione delle macchine virtuali non in linea da technet.microsoft.com/cc501231.

Peter SkjØtt Larsen è Senior Product Manager presso Microsoft. Prima dell'assunzione presso Microsoft, Peter si è occupato dell'architettura e dello sviluppo di software gestionali per il settore delle telecomunicazioni e della standardizzazione e dello sviluppo di servizi wireless.
Suveen Kumar Reddy Vuppala è Senior Software Development Engineer presso Microsoft. Negli ultimi sette anni si è occupato della progettazione e dello sviluppo di strumenti di monitoraggio in tempo reale e della distribuzione di soluzioni per Microsoft.


Windows PowerShell Potenza dei profili
Don Jones

Indice
Shell, host e profili
Utilizzo del proprio profilo?
Creazione di una console personalizzata
Ulteriori suggerimenti sui profili
Attenzione al profilo!
Chi legge regolarmente questa rubrica ormai sa che Windows PowerShell supporta un sistema di profili. Essenzialmente, si tratta di script della shell, con estensione .ps1, che vengono eseguiti automaticamente quando la shell è in funzione. Ad esempio, sono molto utili per la definizione di alias personalizzati. Il profilo può essere impostato in modo che definisca automaticamente gli alias quando la shell è in esecuzione, rendendoli disponibili a ogni utilizzo.
La shell definisce i quattro profili seguenti:
  • un profilo applicabile a tutte le shell e a tutti gli utenti del computer;
  • un profilo applicabile a tutti gli utenti, ma solo alla shell Microsoft PowerShell;
  • un profilo applicabile all'utente corrente e a tutte le shell;
  • un profilo applicabile all'utente corrente e solo alla shell Microsoft PowerShell.
Il concetto "tutte le shell" può creare confusione, poiché la terminologia si riferisce a idee relative alle prime fasi di sviluppo di Windows PowerShell non inserite nel prodotto finale. Attualmente, il termine più appropriato è probabilmente "tutti gli host".

Video
Don Jones dimostra come creare profili per la personalizzazione della shell Windows PowerShell.

Shell, host e profili
Windows PowerShell è una serie di assembly di Microsoft .NET Framework. Di solito definisco questa parte della shell come il motore di Windows PowerShell, poiché contiene la funzionalità che di solito si associa a Windows PowerShell. Non esiste, però, una funzionalità incorporata che consenta agli esseri umani di interagire con il motore: per utilizzare effettivamente la shell, il motore deve essere caricato su un'applicazione host (o sull'host).
L'applicazione powershell.exe che viene eseguita di solito è un host, così come l'applicazione gpowershell.exe inclusa nella Windows PowerShell 2.0 Community Technology Preview (CTP). In realtà, la relazione tra host e shell non è così immediata come viene descritta in questo articolo, ma si tratta comunque di una spiegazione semplificata che ne descrive il funzionamento.
È importante capire che, quando si interagisce con la shell mediante un'interfaccia testuale a riga di comando, si sta probabilmente utilizzando l'host powershell.exe. Ciò accade anche quando si avvia la shell con un collegamento installato da un'altra applicazione, come Exchange Management Shell. Exchange Management Shell non è una shell o una applicazione host diversa, ma semplicemente l'host powershell.exe avviato utilizzando un collegamento che specifica una serie di snap-in e script da precaricare. Gli snap-in attivano la funzionalità di Exchange Management Shell all'interno della shell, ma la shell utilizzata è sempre la stessa.
I percorsi (in Windows Vista) dei profili per l'host powershell.exe sono i seguenti:
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1: per tutti gli utenti del computer e per tutte le shell;
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1: per tutti gli utenti del computer, ma solo per la shell Microsoft PowerShell;
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1: solo per l'utente corrente, ma per tutte le shell;
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1: solo per l'utente corrente e per la shell Microsoft PowerShell.
I profili non sono predefiniti ed esistono solo se vengono creati.
Ciascuna applicazione host deve caricare ed eseguire il profilo corretto. Se una particolare applicazione host "decide" di non caricare alcun profilo è perché, in realtà, non deve: Il profilo, infatti, non viene eseguito automaticamente dal motore di Windows PowerShell.
Per controllare i profili, il metodo più semplice è aprire la shell, digitare $profile e premere Invio. In questo modo si visualizza il percorso completo che la shell tenta di utilizzare per quello che si può intendere come profilo "principale" (il profilo per il singolo utente e specifico per la shell). È possibile creare e modificare lo script da eseguire a ogni avvio della shell.

Utilizzo del proprio profilo
Come suggerito in precedenza, un utilizzo diffuso del profilo è la definizione di alias personalizzati o l'aggiunta di PSDrive personalizzati (unità connesse che esistono interamente all'interno di Windows PowerShell). Un utilizzo meno comune è la creazione di un tipo di super-shell che può svolgere qualsiasi attività di gestione necessaria, in base ai prodotti software utilizzati nell'ambiente. Per spiegare con precisione il concetto di super-shell, sono necessarie alcune informazioni di carattere generale.
Il gruppo di sviluppo di Microsoft che produce Windows PowerShell si occupa di molte altre tecnologie core di gestione, tra cui Microsoft Management Console (MMC). MMC fornisce un'analogia adatta a spiegare il funzionamento di Windows PowerShell. All'avvio di mmc.exe, viene visualizzata una console vuota che non è molto utile, infatti per creare una console funzionale si aggiungono snap-in di MMC.
Una volta configurata la console nel modo desiderato, è possibile salvarla in un file con estensione .msc, grazie il quale si può ricaricare velocemente la console personalizzata in qualsiasi momento.
Molti amministratori utilizzano le console installate con i prodotti che gestiscono, anziché console MMC personalizzate. Exchange Server, ad esempio, crea una console che contiene solo lo snap-in Exchange Server. Utenti e computer di Active Directory è un'altra console creata in precedenza che contiene un singolo snap-in.
Windows PowerShell funziona secondo lo stesso principio. L'icona di Exchange Management Shell installata con gli strumenti di gestione di Exchange Server 2007 è in realtà un collegamento a powershell.exe con le istruzioni per il caricamento di un file di console. I file di console della shell hanno estensione .psc1 e contengono un elenco di snap-in da precaricare (più o meno come un file .msc contiene un elenco di snap-in che vengono precaricati da MMC). Tuttavia, non si è obbligati a utilizzare le console già esistenti della shell, ma si possono creare console personalizzate (proprio come in MMC) da utilizzare per qualsiasi attività di gestione. I profili assumono un ruolo fondamentale in questa operazione.

Creazione di una console personalizzata
Il primo passo per la creazione di una console personalizzata è l'individuazione del nome completo di ogni snap-in su cui si intende lavorare. Accertarsi che tutti gli strumenti di gestione necessari siano installati sul computer. In seguito, in Windows PowerShell, eseguire il comando Get-PSSnapin –registered per ottenere un elenco di tutti gli snap-in registrati disponibili, ma ancora non caricati e creare o modificare il profilo appropriato di Windows PowerShell. Inserire i comandi Add-PSSnapin per caricare gli snap-in che si desidera siano sempre disponibili: si possono includere snap-in per Exchange Server, prodotti System Center e snap-in di terze parti, come PowerShell Community Extensions. A questo punto, salvare il profilo (ricordarsi di aggiungere la firma digitale al profilo, se i criteri di esecuzione di Windows PowerShell lo richiedono) e chiudere la shell. Quando si riapre la shell, vengono caricati automaticamente tutti gli snap-in elencati nel profilo.
Un'altra tecnica consiste nel caricare tutti gli snap-in nella shell (utilizzando Add-PSSnapin e i nomi degli snap-in), quindi eseguire Export-Console per creare un file di console .psc1 con tutti gli snap-in utilizzati attualmente. Questo file può essere quindi utilizzato per creare un nuovo collegamento di Windows PowerShell che specifica il parametro PSConsoleFile e il file .psc1 personalizzato. Mediante il collegamento, la console caricherà automaticamente tutti gli snap-in specificati.

Ulteriori suggerimenti sui profili
Io utilizzo un profilo personalizzato di Windows PowerShell per eseguire molte altre attività utili a ogni avvio della shell. Ecco alcuni esempi di ciò accade all'avvio della shell nel mio sistema:
  1. Eseguendo il comando Get-Credential per l'account di amministratore di dominio, i risultati vengono memorizzati in una variabile denominata $cred che viene resa disponibile nella shell. In seguito la variabile viene passata al parametro -credential di vari cmdlet, come il cmdlet Get-WmiObject e, poiché $cred memorizza la password, i cmdlet in questione possono essere utilizzati senza che venga richiesto l'inserimento di una password.
  2. Eseguendo il comando Cd C:\, la shell si avvia nella directory principale dell'unità C: del computer.
  3. Eseguendo il comando New-Alias per Out-File per creare un alias denominato "of", si può utilizzare "of" al posto di "Out-file". Utilizzo spesso questa tecnica, perché è pratico avere un alias breve definito.
Se nel tentativo di creare una chiave di prova nell'unità HKLM: della shell, che rappresenta la porzione HKEY_LOCALE_MACHINE del registro di sistema, si verifica un errore, significa che la shell è stata avviata senza privilegi elevati. Di solito richiedo privilegi elevati per il lavoro che svolgo e questo è un modo rapido per sapere se li ho ottenuti prima di cominciare a lavorare seriamente.
Si può definire una funzione personalizzata denominata Ping-Address che accetta il nome di un computer o un indirizzo IP e restituisce un valore True o False, a seconda che sia possibile eseguire il ping del computer o meno. Nel mio lavoro utilizzo spesso questa funzione, quindi definendola nel mio profilo, diventa disponibile globalmente nella shell.

Cmdlet del mese: Get-WmiObject
Agli osservatori più attenti non sarà sfuggito il fatto che mi sto occupando di un cmdlet che ho trattato in precedenza, ma ora intendo illustrare una caratteristica estremamente utile che esso offre. Spesso gli amministratori tentano di recuperare le informazioni di Strumentazione gestione Windows (WMI) da più computer, i cui nomi sono elencati in un file di testo, utilizzando questa tecnica:
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
Questa tecnica funziona, ma in realtà non è necessaria, in quanto il cmdlet Get-WmiObject accetta un array di nomi di computer per il parametro -computerName. Per ottenere lo stesso risultato, si può quindi utilizzare la tecnica seguente:
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
Se si colloca il comando Get-Content fra parentesi, si obbliga la shell a eseguirlo e a inserire i risultati (un array di nomi di computer) nel parametro -computerName.
Attenzione al profilo!
Powershell.exe non è la sola applicazione che carica profili Microsoft.PowerShell o profili applicabili a tutte le shell. Anche molti ambienti di sviluppo integrati (IDE), che forniscono il supporto per Windows PowerShell (tra cui PrimalScript di SAPIEN Technologies, PowerGUI di Quest Software e PowerShell Plus di ShellTools), caricano gli stessi profili per offrire un'esperienza analoga all'host di powershell.exe.
Un profilo di grandi dimensioni che carica molti snap-in potrebbe causare un avvio più lento di queste applicazioni, perché sono presenti molte istruzioni per il motore Windows PowerShell da eseguire prima che sia pronto per l'applicazione host. Infatti, perfino powershell.exe può impiegare molto tempo ad avviarsi se deve eseguire uno script del profilo molto esteso.
Inoltre, gli snap-in che definiscono cmdlet con nomi identici possono causare conflitti, ad esempio, se due snap-in definiscono un cmdlet denominato Get-User, Windows PowerShell non eseguirà i cmdlet finché non si utilizza il nome completo del cmdlet per specificare quale si intende usare. Il nome completo può creare problemi, poiché i nomi degli snap-in possono essere piuttosto lunghi. In genere, quando si verificano questi errori, evito di far caricare contemporaneamente i due snap-in, caricando solo quello che utilizzo più spesso nel mio profilo e, se necessario, utilizzando una shell separata per caricare l'altro.
I profili di Windows PowerShell possono aggiungere molti vantaggi alla shell ma, se modificati in modo dannoso da malware, possono provocare seri danni. Si può proteggere il proprio profilo aggiungendo una firma digitale e configurando i criteri di esecuzione di Windows PowerShell su AllSigned oppure modificando tutti i permessi del file NTFS, per evitare che un account utente normale possa modificarli.

Don Jones è l'autore di Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. È possibile contattarlo tramite il sito Web PowerShellCommunity.org.


Hey, Scripting Guy! Le ultime parole famose
Microsoft Scripting Guys

Il famoso filosofo greco Socrate (che morì nel 399 a.C., poco prima che nascesse l'editor di script) è noto per aver affermato che "una vita senza ricerca non vale la pena di essere vissuta". La maggior parte degli utenti conoscerà questo detto. Tuttavia, di recente gli Scripting Guy hanno rivelato, con grande stupore, che Socrate non ha mai pronunciato tali parole. Sembra, infatti, che si tratti di un errore di traduzione commesso da uno scriba medievale centinaia di anni fa. La frase che Socrate pronunciò in realtà è: "Non vale la pena avere un file XML non esaminato".
Questa sì che è una massima filosofica che ha senso! Ultimamente, il formato XML sta acquisendo sempre più popolarità: da una rapida ricerca eseguita sul computer di prova di uno degli Scripting Guy sono risultati oltre 500 file XML utilizzati da diversi sistemi o applicazioni.
Inutile dire che, oggi, una grande quantità di dati importanti è memorizzata in formato XML, senza che questo crei problemi, a patto che, ovviamente, i dati siano esaminati. Purtroppo, ciò non accade spesso, se non altro, perché molti utenti non hanno la benché minima idea di come esaminare un file XML. In particolare, non hanno idea di come eseguire una query e una ricerca all'interno di file di questo tipo.
Nota: per chi non se ne intende di filosofi greci, Socrate era un grande sostenitore del dialogo, ma non sosteneva con altrettanto fervore l'azione; infatti, sua moglie, Santippe, lo chiamava "pigro buono a nulla". Ora è chiaro il motivo per cui gli Scripting Guy hanno un debole per Socrate.
Naturalmente, qualche lettore a questo punto potrebbe pensare: "Aspetta un attimo: gli Scripting Guy non si sono già occupati della ricerca nei file XML in un articolo precedente ("Inseguire automobili... e XML" all'indirizzo technet.microsoft.com/magazine/cc162506)? Se è così, perché hanno deciso di ritornare sull'argomento? Sono talmente pigri che riscriveranno lo stesso articolo all'infinito?"
Si creda o no, siamo anche più pigri di così. Tuttavia, questo non è il motivo primario per cui stiamo riprendendo l'argomento. Nell'articolo precedente si illustrava l'utilizzo di un file XML con una struttura simile al codice riportato nella Figura 1, in cui ciascun valore della proprietà rappresentava un nodo all'interno del file.
Figura 1 File XML solo con nodi
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
Si tratta di una struttura efficiente, tuttavia, come alcuni lettori hanno prontamente sottolineato, non è l'unica di cui un file XML può disporre. Nell'esempio precedente ogni computer nel file ha il proprio nodo; a sua volta, ciascuno dei nodi ha numerosi nodi figlio (sistema operativo, reparto e nome). Tuttavia, è anche possibile costruire un file XML in cui i singoli nodi non abbiano nodi figlio: in questo caso, i valori aggiuntivi delle proprietà sono configurati come attributi, come nel file nella Figura 2.
Figura 2 File XML con attributi
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
Questo è un problema? In effetti, sì. Lo script illustrato in un numero di molto tempo fa non funziona con un file XML strutturato come quello illustrato nella Figura 2. Non può funzionare e questo è indubbiamente un problema, poiché molti degli utenti devono poter leggere questo tipo di file XML.
Bene, bastava chiedere. O meglio, chiedere e aspettare un anno e mezzo prima che riuscissimo finalmente a occuparci di questo problema.
Prima di proseguire, si esaminerà nel dettaglio il file XML. In questo caso il file contiene un nodo primario denominato HARDWARE e ogni singolo computer esiste sotto forma di nodo figlio di HARDWARE. Inoltre, ciascuno dei nodi ha una coppia di attributi: os (utilizzato per memorizzare il nome del sistema operativo installato sul computer) e department (utilizzato per memorizzare il nome del reparto cui appartiene il computer).
Si supponga, ad esempio, di voler ottenere un elenco di tutti i computer che utilizzano Windows XP. È possibile farlo utilizzando uno script? Ovviamente sì:
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
vediamo come. Per iniziare, occorre creare un'istanza dell'oggetto Microsoft.XMLDOM. Come indica il nome, si tratta di un oggetto che consente di operare con file XML. Una volta creato l'oggetto, si imposta la proprietà Async su False: in tal modo lo script apprende che si desidera caricare il documento in modo sincrono anziché asincrono. Perché questa informazione è rilevante per lo script? A essere onesti, è probabile che per lui non lo sia: dopo tutto, gli script (come gli Scripting Guy) sono oggetti inanimati.
Tuttavia, per gli utenti lo è. Se si carica il documento in modo asincrono, infatti, l'esecuzione dello script continua anche quando il documento non è stato ancora caricato completamente. Questa operazione non è accettabile: è facile immaginare i problemi che si possono verificare quando si tenta di eseguire un'attività su un documento che non esiste ancora. Il caricamento sincrono di un file XML garantisce che il file sia completamente caricato prima che lo script proceda.
Per un'incredibile coincidenza, eccoci al punto in cui viene caricato il file XML. Per eseguire l'operazione, si richiama il metodo Load e si apre il file C:\Scripts\HARDWARE.xml, in cui è possibile visualizzare la seguente riga di codice:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
In questo caso viene utilizzato il metodo selectNodes per eseguire una query sul file XML e comunicare allo script i nodi XML da recuperare. La sintassi, in effetti, è un po' insolita.
Innanzitutto, occorre specificare il percorso all'interno del file XML. Questo contiene un nodo di livello superiore denominato HARDWARE, seguito da una serie di nodi di secondo livello denominati COMPUTER. Ciascuno dei nodi rappresenta un singolo record all'interno del file di dati XML. Questa è la ragione per cui la query selectNodes inizia come segue:
//HARDWARE/COMPUTER
A questo punto, si incontra la seguente costruzione:
[@os='Windows XP']
È una porzione di query simile a una clausola WHERE in una query SQL standard. Con SQL, si può utilizzare una query di database simile a questa per ottenere un elenco di tutti i computer che utilizzano il sistema operativo Windows XP:
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
Con il metodo selectNodes, si esegue qualcosa di simile: si richiede di restituire un elenco di tutti i computer in cui l'attributo os (@os) è uguale a Windows XP. Per specificare che si tratta di una clausola WHERE, questa viene inserita per intero tra parentesi quadre.
Nota: questo tipo di query è noto come query XPath. Per ulteriori informazioni su XPath, consultare l'articolo all'indirizzo msdn.microsoft.com/library/ms256115.aspx.
Come già detto, è un po' strano, ma funziona. Se invece si volesse ottenere un elenco di tutti i computer che appartengono al reparto amministrativo? Semplice: il codice per il richiamo di selectNodes avrebbe il seguente aspetto:
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
Ancora una volta, la clausola WHERE è tra parentesi quadre, il nome dell'attributo (department) è preceduto dal simbolo chiocciola (@), quindi viene indicato il valore di interesse.
Facile, vero?
Dopo aver richiamato il metodo selectNodes, per visualizzare i nomi dei computer è sufficiente eseguire un loop nell'elenco dei valori restituiti e inserire un'istruzione Echo per la proprietà Text come illustrato di seguito:
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
Che tipo di informazioni si possono ottenere? A dire la verità, ci si aspetta esattamente di ottenere informazioni come queste:
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
In altre parole, vengono restituiti i nomi di tutti i computer che utilizzano ancora Windows XP.
A proposito, è possibile ottenere anche altro oltre al nome del computer: poiché si tratta del valore "predefinito" per ogni nodo, è semplicemente ciò che si ottiene facendo riferimento alla proprietà Text.
In alternativa, è possibile specificare esattamente i valori dell'attributo che si desidera ottenere. Come esempio si può esaminare il seguente loop For Each modificato:
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
Come si può notare, in questo loop viene ancora applicata la funzione Echo alla proprietà Text; tuttavia, è stata anche aggiunta la seguente riga di codice:
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
In questo caso si utilizza il metodo getNamedItem per recuperare il valore dell'attributo department, quindi si applica la funzione Echo alla proprietà Text per l'attributo. In tal modo è possibile specificare quali valori dell'attributo vengano visualizzati (e non) sulla schermata (si noti che è stato aggiunto il comando Wscript.Echo per inserire una riga vuota tra i record). Quando si esegue questo script, il risultato che si ottiene è il seguente:
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
Se necessario, si possono scrivere query più complesse. Ad esempio, si supponga che si desideri ottenere un elenco di tutti i computer che utilizzano Windows XP o Windows Vista. In SQL questa operazione si esegue scrivendo una query OR. Ebbene, la procedura per eseguire una query su un file XML è identica.
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
Ecco come si ottiene questo risultato: in un'unica serie di parentesi quadre sono stati forniti due criteri: @os='Windows XP' or @os='Windows Vista'. Con questo semplice comando, il risultato sarà simile a quello riportato nella Figura 3.
Figura 3 Risultato della query OR
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
Ricontrollando il file XML, si noterà che i computer che utilizzano Windows XP o Windows Vista sono elencati nell'output, mentre non lo sono quelli che utilizzano Windows Server 2003 o Windows Server 2008. Né dovrebbero esserlo.
Ci sono domande? Si deve scrivere una query più limitata, che restituisca solo i computer che utilizzano Windows XP e appartengono al reparto amministrativo? Come si può immaginare, è un'operazione semplice, infatti è sufficiente scrivere una query AND come la seguente:
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
Così facendo, verrà restituito il seguente set di dati:
atl-ws-002
Finance
Perché nel report è presente un unico elemento? Esatto: perché nel reparto amministrativo è presente un solo computer che utilizza Windows XP.
Speriamo di aver aiutato i lettori a occuparsi di questo specifico tipo di file XML. Se si dovesse scoprire l'esistenza di un ennesimo tipo di file XML, beh, buona fortuna.
Avendo iniziato l'articolo di questo mese con un famoso detto, ci sembra appropriato terminare con qualcosa di simile. Quindi vogliamo chiudere con le parole dell'imperatore Guglielmo II, che a noi Scripting Guy stanno molto a cuore: "Rinuncio per sempre al trono di Prussia e al trono imperiale tedesco a esso connesso".
Il rompicapo di script del Dottor Scripto
La sfida mensile che verifica non solo l'abilità nella risoluzione degli enigmi, ma anche le competenze di scripting.

Ottobre 2008: Cruciverba di VBScript
Per risolvere questo enigma, completare ciascuna riga con il nome di una funzione VBScript. Al termine, riordinare le lettere nelle caselle blu per scoprire il nome di un'ulteriore funzione.

RISPOSTA:
Il rompicapo di script del Dottor Scripto
Risposta: Ottobre 2008: Cruciverba di VBScript

Gli Scripting Guy, Greg Stemp e Jean Ross, lavorano per Microsoft.


The Desktop Files Personalizzazione di Servizi di distribuzione Windows
Wes Miller

Indice
Sostituzione dei componenti esistenti
Descrizione dello stack
Programma di avvio di rete
Provider PXE di Servizi di distribuzione Windows
TFTP Daemon
Archivio dati di configurazione di avvio
Windows PE
Server di trasporto
Multicast personalizzato
Conclusioni
Negli ultimi tre articoli mi sono occupato di Servizi di distribuzione Windows (WDS), partendo dalle origini, fornendo poi panoramica, per trattare successivamente in dettaglio alcuni argomenti avanzati, quali WDSUtil e multicast. In questo articolo, che conclude la serie, illustrerò dove e come sia possibile personalizzare e configurare WDS per soddisfare le esigenze della propria organizzazione. La maggior parte degli strumenti Microsoft sono progettati con un determinato numero di elementi configurabili. Tuttavia, solo quando si passa all'utilizzo pratico, si scopre se gli strumenti sono davvero in grado di soddisfare le proprie esigenze oppure se, come più spesso accade, siano necessarie ulteriori modifiche per adattarli agli scenari esistenti.

Sostituzione dei componenti esistenti
Ultimamente, i lettori mi hanno posto spesso questa domanda: "Utilizzo x (una tecnologia di distribuzione esistente): WDS è adatto nel mio caso ed è disponibile con la funzione di parità con x?" Con la rimozione di Servizi di distribuzione automatica (ADS), una questione di particolare interesse è come riuscire a eseguire rapide distribuzioni di elevati volumi o riconfigurazioni di server e se WDS sia adatto per tali operazioni.
Sebbene WDS non sia stato progettato per sostituire in tutto e per tutto ADS, e in effetti mancano alcuni componenti chiave per poterlo considerare un vero sostituto, apportando determinate modifiche è possibile utilizzarlo al posto di ADS. Analogamente, se alcuni aspetti di WDS non sono adatti per alcuni scenari, molti dei relativi componenti possono essere sostituiti, con diversi livelli di complessità e progettazione. Di seguito sarà descritta la distribuzione tramite WDS, esaminando i componenti che si possono personalizzare e le procedure da seguire a questo scopo.

Descrizione dello stack
Nella Figura 1 vengono illustrati i componenti del processo di distribuzione di WDS. Ciascuna di queste fasi può essere parzialmente personalizzata. A ogni fase è assegnato un colore che ne rispecchia la complessità, ossia in generale le competenze in termini di sviluppo necessarie per sostituire o personalizzare un componente. Le fasi blu scuro sono quelle in cui la personalizzazione è più complessa.
Figura 1 Complessità della personalizzazione di WDS
È ovvio che la reale difficoltà di personalizzazione di ciascuna fase dipende sia dalle competenze (relative a sviluppo o creazione di script) del team che se ne occupa, sia dal livello di conoscenza di WDS, WIM (Windows Imaging Format), Active Directory o qualsiasi altra tecnologia che si intende integrare, ad esempio SQL o ADSI. Di seguito sarà esaminata ognuna di queste fasi: i lettori potranno riflettere sulle modalità con cui eseguire la personalizzazione e ai metodi applicabili.

Programma di avvio di rete
È improbabile che sia necessario creare un programma di avvio di rete (NBP) personalizzato per sostituire quello fornito con WDS, ma è possibile. WDS include alcuni NBP che possono essere utilizzati con sistemi headless (in generale, server) o sistemi in cui si desidera o meno che venga richiesto di premere il tasto F12 per l'avvio e così via. Gli NBP possono essere gestiti in Active Directory mediante WDSUtil, oppure è possibile sostituire Startrom.com con l'NBP da utilizzare per tutti i sistemi che non sono predisposti (ad esempio, se tutti i sistemi in uso sono headless o si desidera non utilizzare mai un prompt F12).
Purtroppo, la documentazione disponibile sulla creazione di NBP non è molto estesa (per alcune informazioni, visitare il sito msdn.microsoft.com/library/bb870970.aspx). Un NBP è un file eseguibile a 16 bit di dimensioni molto ridotte, che presenta rigide restrizioni e richiede specifiche competenze di programmazione. In generale, si consiglia di utilizzare gli NBP esistenti forniti con WDS, a meno che non sia necessario soddisfare requisiti assai specifici e si disponga di un team di sviluppo con competenze adeguate.

Provider PXE di Servizi di distribuzione Windows
Con Servizi di installazione remota (RIS), tra i commenti e suggerimenti dei clienti si riscontrava un desiderio comune di utilizzare un archivio dati diverso da Active Directory per le informazioni sui sistemi client, nella maggior parte dei casi SQL Server. Con WDS, la progettazione prevede un'infrastruttura collegabile per provider Pre-Boot eXecution Environment (PXE). Questo significa che, con un po' di sviluppo, è possibile utilizzare un altro archivio di backup oltre ad Active Directory per le informazioni PXE.
WDS è fornito con il relativo provider che utilizza Active Directory. System Center Configuration Manager (SCCM) si collega ora a WDS e implementa un proprio provider. La documentazione sulla scrittura di un provider personalizzato scarseggia e non è disponibile molto codice di esempio (sebbene il Windows SDK fornisca documenti e un paio di esempi), quindi si tratta di un'attività complessa. A meno che non si debbano soddisfare esigenze davvero specifiche per questo aspetto del processo di avvio, anche in questo caso non è consigliabile tentare di creare un provider PXE personalizzato.

TFTP Daemon
Prima che WDS fosse distribuito, alcuni clienti hanno investito nella creazione di un proprio protocollo Trivial File Transfer Protocol Daemon (TFTPD). Poiché i server PXE non si adattano facilmente tra loro, spesso questo significa utilizzarne uno solo.
In base alle esperienze avute finora, in genere questo comporta l'utilizzo di un TFTPD esistente, di solito basato su Linux, che viene trasformato in modo da avviare altri sistemi operativi. Con l'infrastruttura originale utilizzata dal RIS, questa operazione non sarebbe stata possibile. Tuttavia, da quando l'avvio da RAMDisk è diventato la norma, l'operazione è possibile e si può eseguire utilizzando immagini di avvio basate su WDS.
È importante ricordare che si tratta di un'area priva di supporto tecnico per quanto riguarda Microsoft e che, nella maggior parte dei casi, può causare problemi difficili da diagnosticare. Inoltre, l'ottimizzazione del TFTPD in WDS non garantisce prestazioni migliori. In generale, è consigliabile utilizzare il TFTPD esistente di WDS, cercando di sfruttare timeout, gestione e/o margini di rete del server PXE per definire quali client eseguono l'avvio da determinati server PXE, anziché tentare di modellare un server esistente sulle proprie esigenze.

Archivio dati di configurazione di avvio
Con RIS, al livello di avvio non era possibile specificare gli elementi da inizializzare: era infatti necessario selezionare dapprima il sistema operativo, quindi un'opzione (configurazione, Windows PE - Windows Preinstallation Environment - o altro). WDS invece, poiché utilizza un caricatore completo per l'avvio di rete, supporta anche la personalizzazione dell'archivio dei dati di configurazione di avvio (BCD) fornito ai client. L'archivio BCD predefinito per tutte le architetture si trova in RemoteInstall\Boot\<arch>\Default.bcd, dove <arch> è l'architettura specifica del sistema che viene inizializzato.
È possibile personalizzare il BCD per ciascun client, che lo utilizzerà per l'avvio. Ad esempio, si può impostare una voce BCD che avvia l'installazione, un'altra per l'esecuzione di Ambiente ripristino Windows (WinRE) e un'altra ancora per l'esecuzione di un test sulla memoria. In alternativa, si può impostare una voce di installazione automatica come opzione predefinita e una voce manuale (o di procedura di installazione personalizzata) come opzione selezionabile da parte dell'utente (per ulteriori informazioni, consultare l'articolo sulle modalità di modifica dell'archivio BCD tramite l'utilizzo di Bcdedit all'indirizzo go.microsoft.com/fwlink/?LinkId=115267).

Naturalmente, la maggior parte delle operazioni di WDS sono svolte in Windows PE, pertanto la modifica dell'ambiente al fine di soddisfare le proprie esigenze può rappresentare un'area critica su cui concentrare l'attenzione per una procedura di installazione personalizzata. Per impostazione predefinita, WDS fornisce un modello standard per l'installazione, che include la procedura di installazione completa. A seconda delle proprie esigenze di distribuzione, questa soluzione potrebbe non risultare adeguata. In tal caso è possibile creare la propria immagine di avvio di Windows PE. È opportuno partire dall'inizio.
Oltre a usare BCD per indicare quale immagine utilizzare, è possibile specificare l'immagine personalizzando l'oggetto account (MAO) per un computer in Active Directory. In RIS un attributo MAO specifico memorizzava ciascun elemento (il file Startrom e di installazione automatica, SIF, da utilizzare). Con WDS, questi sono memorizzati come coppie nome-valore in corrispondenza della voce netBootMirrorDataFile. Ad esempio, in questa voce sono memorizzati l'immagine di avvio e il file di installazione automatica che un determinato computer deve utilizzare. La forma delle voci è un elenco di coppie nome-valore delimitate da punto e virgola. Le voci per modificare l'immagine di avvio e il file di installazione automatica sono rispettivamente BootImage e UnattendFilePath.
È naturalmente possibile che sia necessario eliminare completamente la procedura di installazione esistente e crearne una personalizzata. Ad esempio, potrebbe essere necessaria una maggiore configurabilità, una maggiore automazione o un build automatizzato da SQL Server. Potrebbe inoltre essere necessario realizzare, come alcuni clienti hanno fatto in precedenza per RIS e Windows PE, un front-end personalizzato per l'installazione. Le attività principali che occorre svolgere, indipendentemente dalla procedura di installazione che si sta scrivendo, sono le seguenti:
  • Scoprire qualsiasi informazione specifica su computer o utenti. Queste informazioni si possono ottenere tramite gli utenti o, ad esempio, tramite SQL Server o un file di testo.
  • Copiare e applicare un'immagine di installazione al sistema client. È possibile svolgere tale attività utilizzando direttamente l'installazione, utilizzando ImageX per applicare un'immagine da una condivisione di rete o tramite multicast (copiare semplicemente l'immagine e applicarla tramite ImageX).
  • Fornire un file di installazione automatica (ad esempio, Unattend.xml o sysprep.inf, a seconda della versione di Windows distribuita) per completare l'installazione.
  • Automatizzare qualsiasi fase di migrazione post-installazione da eseguire (o qualsiasi passaggio per l'applicazione di ruoli nel caso di Windows Server 2008).
ADS ha introdotto il concetto di sequenze di attività che consentono l'assegnazione di passaggi ripetibili a uno o più computer. Poiché ADS non è stato progettato o supportato per l'utilizzo con Windows XP, non è possibile utilizzarlo per la distribuzione del sistema operativo. Tuttavia, le sequenze di attività ADS sono semplici script strutturati ed è possibile eseguire gli stessi passaggi utilizzando un processo di installazione personalizzato.
Poiché per molto tempo sono stato un sostenitore di Microsoft SQL Server (dalla versione SQL Server 6.5), l'istinto mi suggerisce di realizzare la struttura utilizzando SQL. A tal fine è ovviamente necessario aggiungere al proprio Windows PE la funzionalità SQL. Inoltre, è possibile scrivere la propria GUI (applicazione HTML, HTA o file eseguibile compilato) o utilizzare Windows Script Host (WHS) per eseguire una procedura di installazione minimalista, composta da una sola riga di comando. Per poterli utilizzare, si deve aggiungere a Windows PE anche HTA o WSH.
La complessità della progettazione di una procedura di installazione personalizzata dipende interamente dalle competenze e dall'immaginazione di chi se ne occupa. Ho visto sistemi piuttosto eleganti definiti unicamente utilizzando SQL e WSH oppure HTA, che sono competenze relativamente semplici da acquisire. È molto importante, tuttavia, tenere presenti i vincoli citati negli articoli precedenti:
  • Windows PE non dispone di alcun sottosistema Windows on Windows (WOW), quindi è necessario compilarlo per ciascuna architettura che si intende supportare.
  • Se è necessario eseguire la distribuzione tramite Windows PE x64 o IA64, non è possibile utilizzare Visual Basic 6.0.
  • È possibile utilizzare Visual Studio 2005 o 2008 per creare applicazioni, ma occorre creare un'applicazione Visual C++ non gestita, poiché Windows PE non supporta alcuna versione di Microsoft .NET Framework.
  • Senza .NET Framework, è inoltre impossibile utilizzare Windows PowerShell per l'automazione.
Se si desidera scrivere una procedura di installazione personalizzata, esiste comunque la possibilità di usare utilità di creazione immagini di terze parti anche tramite WDS. Sebbene il formato WIM e ImageX siano in grado di rispondere alle esigenze della maggior parte degli scenari di distribuzione, determinati requisiti possono essere soddisfatti dallo strumento di creazione immagini esistente dell'utente.
Analogamente, alcuni scenari potrebbero richiedere un partizionamento personalizzato, ad esempio nel caso in cui gli utenti distribuiscano Windows Vista con BitLocker oppure creino sistemi Windows XP memorizzando i dati dei profili su un secondo volume o ancora qualora distribuiscano un sistema Windows Server e desiderino creare un volume separato sullo stesso disco per l'accesso. Tutti i casi citati richiedono l'automazione di DiskPart che, come nelle versioni precedenti, può essere eseguita inserendo uno script (qualsiasi formato di file) che contiene il comando da eseguire e che si conclude con exit, per terminare DiskPart.
Creare la propria procedura di installazione non è un compito semplice, poiché occorre in pratica ricostruire il file eseguibile di installazione (o per lo meno eseguire il mirroring delle relative funzionalità) e gli elementi da progettare e realizzare sono molti. Tuttavia, occorre considerare la quantità di funzionalità predefinite da inserire e gli strumenti utilizzati (HTA, WSH o un linguaggio di programmazione compilato).

Server di trasporto
Il server di trasporto può soddisfare le esigenze degli utenti che non utilizzano la maggior parte delle funzionalità integrate di WDS (ad esempio, Active Directory) o che stanno progettando una soluzione personalizzata completa, senza requisiti indesiderati. La tabella nella Figura 2 (tratta dall'articolo sull'utilizzo del server di trasporto all'indirizzo go.microsoft.com/fwlink/?LinkID=115298) descrive gli elementi inclusi nel ruolo del server di trasporto WDS.
Figura 2 Server di distribuzione e server di trasporto a confronto
 | Server di distribuzione | Server di trasporto
Requisiti del server | Richiede la presenza di Servizi di dominio Active Directory (ADDS), Dynamic Host Configuration Protocol (DHCP) e Dynamic Name Services (DNS) nell'ambiente. | Non richiede la presenza di altri server nell'ambiente.
PXE | Supporta l'avvio di PXE con il provider PXE predefinito. | Non è installato alcun provider PXE, pertanto occorre crearne uno personalizzato.
Server immagini | Include il server di immagini WDS. | Non include il server di immagini WDS.
Metodo di trasmissione | Consente trasmissione unicast e multicast. | Consente solo trasmissione multicast.
Strumenti di gestione | È gestito utilizzando lo snap-in MMC di Servizi di distribuzione Windows o lo strumento a riga di comando WDSUTIL. | È gestito solo dallo strumento a riga di comando WDSUTIL.
Applicazione sul computer client | Utilizza il client di Servizi di distribuzione Windows (che in pratica è Setup.exe e file di supporto), Wdsmcast.exe (incluso in Windows AIK) o un'applicazione multicast personalizzato. | Utilizza solo Wdsmcast.exe o un'applicazione personalizzata.
Quando affermo che il server di trasporto è un elemento di difficile implementazione, non mi riferisco al ruolo in sé, che, naturalmente, è semplice da distribuire (vedere Figura 3). Mi riferisco piuttosto all'implementazione dell'installazione personalizzata del server di trasporto, che richiede maggiore impegno. L'utilizzo del ruolo del server di trasporto complica l'utilizzo di WDS come ruolo.
Figura 3 Il server di trasporto può essere utile per scenari di distribuzione personalizzata (fare clic sull'immagine per ingrandirla)

Multicast personalizzato
Che si utilizzi o meno il ruolo del server di trasporto, ma in particolare se viene utilizzato, quando si effettuano distribuzioni a più sistemi risulta utile l'uso del multicast. ADS disponeva di una funzionalità multicast molto efficace, che è possibile duplicare utilizzando WDS con multicast. WDS dispone di un proprio multicast, ma se si intende realizzare una soluzione personalizzata, è possibile sfruttare il multicast utilizzando WDSMCast, come illustrato lo scorso mese (vedere la Figura 4). È bene ricordare che occorre trasferire i file di immagini da distribuire, che devono quindi essere applicati. In generale, è necessaria una quantità sufficiente di spazio sul disco locale affinché l'immagine venga memorizzata e quindi applicata.
Figura 4 Esecuzione di WDSMCast (fare clic sull'immagine per ingrandirla)

Conclusioni
WDS è di per sé un servizio piuttosto efficace ed è probabile che sia sufficiente a soddisfare le esigenze della maggior parte delle aziende. Tuttavia, è possibile realizzare una soluzione personalizzata che superi i confini di WDS: l'unico limite è rappresentato dalla propria immaginazione, dalle proprie competenze e dal tempo a disposizione.

Wes Miller è un Senior Technical Product Manager di CoreTrace (CoreTrace.com) a Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.


Security Watch Riesaminiamo insieme le 10 leggi immutabili della sicurezza, Parte 1
Jesper M. Johansson

Nell'anno 2000, Scott Culp ha pubblicato un saggio dal titolo "Le 10 leggi immutabili della sicurezza". È uno dei migliori saggi sulla sicurezza che abbia mai letto. Le informazioni contenute nel saggio sono fondamentali ancora oggi per ogni attività relativa alla sicurezza dei dati e consiglio a tutti di leggerlo (e di stamparlo) nel caso non l'abbiate già fatto. E' disponibile su microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx.
Il saggio ha suscitato reazioni contrastanti. Alcuni hanno commentato con sarcasmo che in questo modo Microsoft evitava di risolvere quelli che erano considerati gravi problemi. Altri hanno definito il saggio un'opera capitale in materia di sicurezza e, vista la sua eccezionale importanza, lo hanno riprodotto a piacimento. Tuttavia, le reazioni che ho più apprezzato sono state quelle di alcuni utenti che, ispirati dall'opera, hanno creato dei propri elenchi, come quello disponibile su edgeblog.net/2006/10-new-immutable-laws-of-it-security.
Negli otto anni successivi alla pubblicazione di tale saggio, molte cose sono cambiate nel campo della sicurezza. A tale riguardo è stato pubblicato moltissimo materiale. Siamo entrati nell'era della guerra informatica (che coinvolge criminalità organizzata, entità politiche ecc.). Nuove parole e concetti sono entrati a far parte del vocabolario comune, tra cui phishing, pharming, botnet, spyware e cross-site request forgery. Alcuni tra i rootkit più sofisticati mai creati vengono eseguiti in Windows. Alcune nuove versioni dei sistemi operativi tengono conto in larga misura della sicurezza mentre altri ignorano ancora del tutto il problema della sicurezza.
L'ingegneria sociale si è evoluta a tal punto da diventare una delle principali minacce. Le violazioni di dati, come quando un grande venditore al dettaglio ha divulgato 94 milioni di numeri di carte di credito, sono all'ordine del giorno (e gli utenti continuano ancora a fare acquisti in negozi di questo tipo). I governi di Stati Uniti e Regno Unito hanno diffuso le informazioni private di una percentuale considerevole di abitanti dei paesi occidentali (e gli utenti registrano ancora le proprie informazioni personali presso questi governi). E una quantità enorme di misure di sicurezza sono entrate a far parte della nostra vita quotidiana e delle procedure dei nostri aeroporti.
Penso sia giunto il momento di riesaminare queste leggi. Considerati tutti i cambiamenti a cui abbiamo assistito nella prima parte di questo secolo, possiamo ancora affermare che tali leggi sono intoccabili? Se lo sono, e se sono riuscite a sopravvivere agli ultimi 8 anni, possiamo affermare con una certa sicurezza che probabilmente sopravvivranno per altri 10 anni.
In questa serie, suddivisa in tre parti, eseguirò un'analisi critica di ognuna delle 10 leggi. Questo mese mi occuperò delle leggi dalla 1 alla 3. Nel prossimo numero, esaminerò le leggi dalla 4 alla 7 e, nel terzo, analizzerò le leggi dalla 8 alla 10, oltre a cercare di fornire ulteriori spunti di riflessione e commenti a mio avviso sensati alla luce di quanto è successo dall'anno in cui le leggi in questione sono state pubblicate, ovvero il 2000.
Legge 1: Se un utente malintenzionato riesce a convincerti ad eseguire il suo programma sul tuo computer, quello non è più il tuo computer.
Questa legge afferma in maniera efficace che qualsiasi software eseguito sul computer può controllare lo stesso. Quando le leggi immutabili hanno fatto la loro comparsa, i sistemi operativi della Microsoft erano Windows 98, Windows Me e Windows NT 4.0. Oggi abbiamo Windows Vista e Windows Server 2008.
Su Windows 98 e Windows Me, qualsiasi software eseguito aveva il controllo completo del computer. Windows NT 4.0 aveva un modello di sicurezza sottostante molto resistente agli attacchi ma, avviandolo come amministratore, il modello di isolamento veniva declassato al pari di quelli di Windows 98 e Windows Me. Era possibile avviare Windows NT 4.0 senza privilegi amministrativi ma il sistema non funzionava correttamente ed erano pochi coloro che sceglievano questa soluzione (probabilmente il numero di utenti si contava sulle dita di una mano).
Si supponga di aver avviato Windows NT 4.0 senza privilegi amministrativi. Possiamo affermare che la Legge 1 era valida quando è stata scritta? La risposta è sì. Innanzitutto, Windows NT 4.0 presentava numerose e significative lacune. Conteneva ad esempio autorizzazioni che avrebbero potuto essere più restrittive, in particolare quelle relative agli oggetti del kernel e del registro di sistema. Esistevano inoltre molti tipi di attacchi che non erano ancora stati scoperti ma che, a detta degli esperti, sarebbero affiorati presto. Ad esempio, nel 1999 gli utenti non si erano resi conto che eseguendo i processi come utenti privilegiati sul desktop interattivo potevano compromettere l'intero computer. Soltanto nel 2002, quando Chris Paget ha pubblicato il white paper sugli attacchi shatter "Sfruttare l'API Win32", questa rivelazione è diventata di dominio pubblico (seclists.org/bugtraq/2002/Aug/0102.html).
Microsoft aveva previsto gli attacchi shatter quando la Legge 1 è stata scritta? In realtà no. Microsoft ha riconosciuto solamente che: esistono pochi limiti di protezione effettivamente in grado di impedire ad un'applicazione in esecuzione su un computer di prendere il controllo dello stesso.
Windows Vista e Windows Server 2008 sono a due generazioni di distanza da Windows NT 4.0. Hanno forse smentito la Legge 1? Esistono altri sistemi operativi che lo fanno? Dipende. I sistemi operativi più recenti offrono certamente limiti di protezione più efficaci e già nel 2000 alcuni sistemi operativi sperimentali presentavano limiti di protezione invidiabili. Tuttavia, questi limiti sono ancora insufficienti. Ad esempio, Code-Access Security in Microsoft .NET Framework è un limite di protezione. È stato appositamente progettato in modo da impedire ai codici in esecuzione nella sandbox di danneggiare il sistema operativo sottostante.
Iframes di Internet Explorer è un altro limite di protezione. Ma Iframes non interessa l'accesso al sistema operativo, bensì solo l'accesso tra parti di contenuto all'interno di una pagina Web. La Modalità Protetta di Internet Explorer, illustrata nella Figura 1, è un limite di protezione a livello di sistema operativo. Il suo scopo è quello di impedire al codice eseguito all'interno di un browser di danneggiare il sistema operativo sottostante, senza intervento da parte dell'utente. Ne esistono altri, anche se in numero limitato, come gli account utente standard, che in teoria impediscono ad un account utente di danneggiare il sistema operativo sottostante o qualsiasi altro utente.
Figura 1 Internet Explorer 7 utilizza un limite di protezione chiamato Modalità Protetta (Fare clic sull'immagine per ingrandirla)
È molto importante capire cosa si intende con il termine "limite di protezione". Non rappresenta un muro invalicabile che garantisce un isolamento illimitato e totale. Il vero significato del termine è che una società produttrice di software, Microsoft ad esempio, è tenuta a correggere ogni violazione di tale limite tramite una patch di sicurezza. Il software presenterà sempre bug e verranno portate alla luce senza dubbio nuove violazioni, così la società produttrice di software dovrà continuare a correggerle. Con il passare del tempo, tali società dovranno continuare a migliorare i propri software per impedire a queste vulnerabilità di manifestarsi. Tale affermazione sembrerebbe confermare che la Legge 1 è ancora valida.
Tuttavia, vi è ancora un punto, ben più importante, che occorre prendere in considerazione. In precedenza, avrai certamente notato l'espressione "senza intervento da parte dell'utente". La Legge 1 non tratta esattamente i difetti e le vulnerabilità del software. Riguarda in realtà le vulnerabilità degli utenti! Il verbo chiave è "convincerti". Se un utente malintenzionato riesce a convincerti ad eseguire il suo programma, probabilmente lo fa in un contesto che strutturalmente conferisce al programma privilegi elevati.
Anche se non si possiedono privilegi da amministratore ciò potrebbe non fare differenza. Anche in qualità di utente standard, si può avere accesso a numerose informazioni interessanti: documenti bancari, lettere d'amore, fotografie, video e informazioni aziendali riservate. Per un malintenzionato, tutte queste informazioni sono potenzialmente interessanti e tutto questo materiale può essere visionato senza disporre di privilegi elevati. In termini di dati memorizzati sul computer, l'esecuzione di un malware permette ad un utente malintenzionato di avere accesso a tutte le tue azioni. Pertanto, se sei solito definire il "tuo computer" come "l'insieme dei dati presenti sul tuo computer," puoi ignorare tutte le discussioni relative ai privilegi e concludere semplicemente che la Legge 1 è ancora valida.
Senza voler essere eccessivamente pignoli riguardo alla definizione di "tuo computer", sembra proprio che la Legge 1 sia riuscita a resistere al trascorrere del tempo. Il punto chiave della Legge 1 è affermare che tu, in qualità di operatore di un computer, devi assumerti la responsabilità del software in esecuzione su quel determinato computer. Se installi un driver dannoso o un codec video maligno, sei stato tu ad aver consegnato quel computer nelle mani di un criminale!
Sebbene le società produttrici di software siano in grado di fare molto per evitare danni accidentali ed è proprio per questo che vengono prodotti i limiti di protezione, l'esecuzione intenzionale di un software dannoso ha in genere la meglio su tutte le misure di sicurezza adottate. Ed ecco perché formare gli utenti è un punto chiave, oltre a garantire che essi non siano in grado di eseguire attività amministrative. Pertanto, possiamo affermare con certezza che la Legge 1 è tuttora valida, sebbene sia necessario apportare una piccola modifica alla definizione di "tuo computer".
Legge 2: Se un utente malintenzionato è in grado di modificare il sistema operativo del tuo computer, quello non è più il tuo computer.
In apparenza, questa legge sembra essere piuttosto chiara. E' ovvio che se un utente malintenzionato è in grado di modificare il sistema operativo del tuo computer, non puoi più fare affidamento sullo stesso. Tuttavia, il concetto di sistema operativo è cambiato con il mutare delle esigenze informatiche. Diversi anni fa, ho scritto una definizione del termine sistema operativo per The Blackwell Encyclopedia of Management (managementencyclopedia com). In tale definizione si parlava un sistema operativo che gestiva l'accesso alle periferiche di input ed output, all'hardware, eccetera. Finora non ho ancora ricevuto una copia dell'enciclopedia ed il mio contributo originale sarà andato sicuramente perso. Tuttavia, sono certo di non aver mai affermato che un sistema operativo contiene un solitario, un sistema di input tablet e transcoder video.
Poiché l'informatica diventa sempre più complessa, i sistemi operativi si sono evoluti al fine di supportare un numero crescente di funzioni. A complicare ulteriormente le cose, gli OEM contengono spesso numerosi software aggiuntivi che possono essere utili o del tutto dannosi. Alcuni di questi software aggiuntivi moltiplicano le funzionalità già previste nel sistema operativo principale.
Ad esempio, un'installazione predefinita di Windows Server 2008 Enterprise Edition ha una traccia del disco di oltre 5 gigabyte. Windows Vista Ultimate Edition contiene più di 58.000 file ed occupa oltre 10 gigabyte. E non vi sono soltanto file che vanno a comporre il sistema operativo. Mi riferisco, ad esempio, a migliaia di impostazioni di configurazione, oltre a daemon e servizi.
Tutto questo fa parte del sistema operativo. Si tratta di un termine collettivo che contiene tutti i file, le impostazioni di configurazione e i servizi, così come la totalità degli oggetti di runtime, tra cui semafori, named pipes, endpoint RPC, creati dagli stessi file e dalle impostazioni di configurazione. Persino gli elementi più astratti come l'ora del sistema ed alcuni tipi di dati, come i contenuti dei log degli eventi, fanno parte del sistema operativo.
Considerata la crescita e l'evoluzione dei sistemi operativi, è giusto affermare che modificando anche uno solo dei file si rende meno affidabile il computer? La prima risposta, quella spontanea, è no. Ad esempio, Windows Vista è dotato di edlin.exe, il vecchio editor di riga di MS-DOS. Non ne sono certo, ma scommetterei un caffè che, da quando tale sistema operativo è in commercio, edlin.exe è stato avviato solo un paio di volte su tutti gli esemplari venduti. Sono stato io a farlo entrambe le volte, quando circa tre minuti fa stavo cercando di ricordare la sintassi. Se qualcuno modifica edlin.exe o un altro file che non viene mai utilizzato, significa che quel computer non è più il tuo computer?
Edlin.exe è senza dubbio parte del sistema operativo, ma se nessuno esegue il file, come può una semplice modifica compromettere il computer? E' chiaro, la risposta è che non può farlo. Modificare una parte del sistema operativo che non è mai stata utilizzata non compromette affatto un computer. E sono tante le sezioni del sistema operativo che non vengono mai utilizzate.
Nonostante quanto affermato finora, la seconda risposta è sì. Non si può considerare soltanto l'esecuzione di un file finalizzata a verificare se la modifica compromette o meno il computer. La questione è molto più sottile. Prova a dare un'occhiata all'elenco di controllo di accesso (ACL) per edlin.exe, illustrato nella Figura 2.
Figura 2 L'ACL per edlin.exe è molto restrittivo (Fare clic sull'immagine per ingrandirla)
L'ACL per edlin.exe è molto restrittivo. Soltanto il servizio TrustedInstaller ha il diritto di modificare il file eseguibile. Questa affermazione è molto importante: significa che, quando un utente malintenzionato modifica il file in questione sul tuo computer, provoca un effetto indiretto. La modifica di edlin.exe implica quindi che quello non è più il tuo computer. Il fatto rilevante in questo caso è che un utente malintenzionato sia in grado di modificare edlin.exe. Se l'utente malintenzionato riesce a modificare il file, può modificare qualsiasi tipo di file, il che significa che non potrai più fare affidamento su quel computer.
Il sistema operativo si protegge da solo. I servizi sono protetti contro le modifiche non autorizzate. Le impostazioni di configurazione sono protette contro le modifiche non autorizzate. I file su disco sono protetti contro le modifiche non autorizzate. Persino i semafori e gli endpoint RPC utilizzati dal sistema operativo sono protetti contro le modifiche non autorizzate. Se un utente malintenzionato può modificare uno qualsiasi di questi file, significa che è in grado di modificarli tutti, e probabilmente lo ha già fatto.
Questo è ciò che conta. Nelle leggi immutabili, non è l'azione ad indicare che il tuo computer è stato compromesso. Il punto fondamentale è che qualcuno sia in grado di compiere quell'azione. Ciò non va trascurato. In ogni aspetto della sicurezza, occorre sempre tener presente che la capacità è di gran lunga più importante dell'azione stessa.
Se un computer naviga su Internet senza patch di sicurezza per mesi, possiamo ancora definirlo un computer sicuro? No. Il computer è da considerarsi compromesso. Non si può più fare affidamento su un sistema che potrebbe essere stato violato. (Ho affermato esattamente lo stesso cinque anni fa nel mio articolo "Aiuto!" Sono stato attaccato. Che fare ora? disponibile su technet.microsoft.com/library/cc512587.) Se ti stai confrontando con un avversario esperto, è possibile che un sistema compromesso non mostri alcuna traccia di compromissione. Il sistema potrebbe sembrare perfettamente normale.
Senza dubbio, la Legge 2 è ancora valida. Se un utente malintenzionato è in grado di modificare qualsiasi oggetto protetto sul tuo computer, quello non è più il tuo computer. Va tenuto presente che ciò che conta non è modificare concretamente i file, quanto piuttosto essere in grado di farlo.
Legge 3: Se un utente malintenzionato ha accesso fisico illimitato al tuo computer, quello non è più il tuo computer.
Nel 2000 questa legge non venne compresa subito. Molti utenti non si rendevano conto di cosa sia possibile ottenere avendo accesso fisico ad un sistema. Del resto, persino alcune agenzie governative che avrebbero dovuto capirlo meglio di altri, sono rimaste completamente all'oscuro di questo problema. Allora le linee guida sulla sicurezza consigliavano di abilitare lo spegnimento senza che l'opzione di accesso fosse disabilitata. Il tasto Spegni nella schermata di accesso era pertanto grigio. La teoria alla base di questa convinzione era che, per spegnere il computer, l'utente doveva prima effettuare l'accesso, creando in tal modo un registro che permetteva di verificare chi avesse spento il sistema.
Si tratta di un caso esemplare di ragionamento insensato. Per aver accesso al tasto Spegni dalla schermata di accesso, occorre prima di tutto sedersi davanti ad un computer. E se sei seduto al computer e hai davvero intenzione di spegnere il computer, puoi sempre utilizzare il pulsante rotondo sulla parte anteriore del case, o meglio ancora, scollegare il cavo di alimentazione. Il sistema si spegne. E della persona che ha compiuto questa azione non rimane alcuna traccia.
Windows 2000 è dotato di un'impostazione di sicurezza chiamata Consenti il disinserimento senza l'accesso, opzione tuttora disponibile in Windows Vista, come illustrato nella Figura 3. Il principio era lo stesso. Al fine di disinserire un computer portatile dal proprio alloggiamento di espansione è necessario accedere in primo luogo al sistema.
Figura 3 Perché non rubare sia il computer che l'alloggiamento di espansione? (Fare clic sull'immagine per ingrandirla)
La protezione effettiva fornita da questa impostazione è alquanto dubbia. In teoria, se chiunque può arrivare al computer e disinserirlo, allora qualcuno potrebbe rubarlo facilmente. Non che io voglia rubare un computer portatile, ma se volessi farlo, questa misura preventiva di certo non mi dissuaderebbe. Probabilmente, prenderei sia il computer portatile che l'alloggiamento di espansione. Caspita, ruberei anche il cavo di rete e di alimentazione. Si tratta solo di apportare una piccola modifica alla sicurezza!
L'accesso fisico al computer è diventato un argomento d'attualità quando Petter Nordahl-Hagen ha creato Offline NT Password & Registry Editor. La sua creazione era semplicemente un disco di avvio di Linux con un driver del file di sistema NTFS sperimentale che permetteva l'accesso di lettura e scrittura ad un volume NTFS. Il software sul disco di boot montava il Registro di sistema sul computer locale e inseriva una nuova password per l'account amministratore nel SAM (gestione delle risorse software). Occorrevano soltanto l'accesso fisico al sistema ed un paio di minuti.
Era proprio per contrastare simili tool che venne scritta la Legge 3. Infatti il tool di Nordahl-Hagen veniva utilizzato in molte dimostrazioni. Sfortunatamente, la maggior parte degli utenti non ha mai capito il senso di questo problema. Ho utilizzato personalmente il tool in alcune dimostrazioni, poi ho smesso di farlo perché ero stufo di sentirmi ripetere "Come facciamo a garantire che nessuno dei nostri utenti conosca tool come questo?" oppure "Cosa sta facendo Microsoft per risolvere questo problema?" Gran parte dell'industria IT, un fatto allarmante, non voleva accettare o comprendere che l'accesso fisico è il più pericoloso di tutti.
In tale contesto, la Legge 3 è una norma davvero importante. Tuttavia, i critici l'hanno attaccata senza pietà. Veniva derisa come un tentativo di Microsoft di evitare di risolvere i problemi potenzialmente imputabili, anche nei casi più remoti, all'accesso fisico. In diversi casi la legge 3 è stata utilizzata per respingere relazioni sulla vulnerabilità, compresa quella su Offline NT Password & Registry Editor. Bloccare gli utenti malintenzionati che hanno accesso fisico al sistema è possibile in un solo modo: accertandosi che non possano avere accesso a nulla.
È questo il punto debole della Legge 3, apparsa finora inattaccabile. Da quando le leggi sono state pubblicate, le tecnologie di crittografia dei dischi sono diventate sempre più affidabili. Con una crittografia totale del disco rigido, o più correttamente, una crittografia dell'intero volume, un volume completo (quello che negli altri sistemi operativi è chiamato partizione) può essere codificato. Dunque se l'intero volume di avvio (in altre parole, il volume con il sistema operativo) viene codificato, la domanda che dobbiamo farci è questa: la Legge 3 è ancora valida?
La risposta è, senza dubbio, forse. In primo luogo, occorre memorizzare da qualche parte le chiavi di decrittografia. Il posto più semplice dove memorizzare le chiavi, nonché l'opzione predefinita di BitLocker, è un chip Trusted Platforms Module nel computer. In tal modo, il computer non è protetto all'avvio. Una volta che il computer è acceso, un utente malintenzionato, pieno di risorse e ben finanziato, che dispone del controllo fisico permanente sul computer può attaccarlo in innumerevoli modi. Dato che il computer può essere connesso ad una rete arbitraria, esistono diverse modalità correlate alla rete per attaccare il sistema.
Un utente malintenzionato, ad esempio, potrebbe leggere o scrivere una memoria mediante una periferica di accesso diretto alla memoria (DMA), come un'unità di memoria flash USB. Una volta che il computer è acceso e che l'utente malintenzionato ha accesso fisico allo stesso, i giochi sono fatti.
Se le chiavi non sono memorizzate sul computer, il successo dell'attacco dipende dalla possibilità dell'utente malintenzionato di riuscire ad ottenere o indovinare le chiavi. Se per avviare il computer viene utilizzato un codice PIN, è probabile che l'utente malintenzionato indovini il codice in maniera relativamente facile. Se le chiavi sono memorizzate o sono derivate da una periferica hardware separata, ad esempio un'unità di memoria flash USB o una chiave con una password monouso, l'utente malintenzionato deve accedere a tali periferiche separate. Certo, esistono diversi modi per ottenere tali chiavi o per rendere la vita difficile alla persona che ha accesso alle stesse ma, nonostante tutto, lo sforzo richiesto è probabilmente maggiore.
E' anche possibile interpretare la Legge 3 in un modo leggermente differente: "Se l'utente malintenzionato ha accesso fisico al tuo computer, è probabile che il computer sia stato rubato ed è pertanto improbabile che riuscirai a riaverlo". Da questo punto di vista, il computer non è più tuo. E sempre da questo punto di vista, l'utente malintenzionato potrebbe anche non avere interesse ad impossessarsi dei dati sul computer. Tuttavia, non è questa la riflessione alla base della Legge 3. Essa intendeva sottolineare che un utente malintenzionato può accedere ai dati sul tuo computer e non solo al computer stesso.
Considerando tutto ciò, possiamo affermare che la Legge 3 è ancora valida. Senza dubbio alcune delle tecnologie odierne hanno fatto grandi progressi per impedire ad utenti malintenzionati di avere accesso fisico ad un computer, limitando in tal modo il numero di utenti in grado di avere accesso ai dati di un computer in cui sono presenti misure di sicurezza. Detto questo, sono le capacità di un utente malintenzionato a stabilire fino a che punto egli si potrà spingere e le nuove tecnologie tengono conto di molte problematiche messe in evidenza dalle 10 leggi immutabili. Ma l'accesso fisico offre ancora la possibilità, anche se più complicata, di entrare in un sistema.
Fino ad oggi le leggi immutabili della sicurezza si sono dimostrate molto adattabili, sia rispetto ai progressi tecnologici che al passare del tempo. Delle prime 3 leggi, la terza è la più instabile, sebbene in alcuni casi sia ancora valida. Si tratta, tuttavia, della legge che presenta le attenuazioni più solide e più facilmente disponibili. Nei prossimi due numeri di TechNet Magazine riprenderò questo argomento per stabilire se le Leggi dalla 4 alla 10 sono ancora valide.

Jesper M. Johansson, è un Software Architect e si occupa della sicurezza dei software. Collabora inoltre con la rivista TechNet Magazine in qualità di redattore. Ha conseguito un dottorato in gestione dei sistemi informatici, vanta un'esperienza più che ventennale sul tema della sicurezza; è inoltre Microsoft Most Valuable Professional (MVP) per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.


Field Notes Codice a barre a colori ad alta capacità
Gavin Jancke

I codici a barre sono ormai un elemento talmente familiare da passare spesso inosservati. Eppure sono praticamente onnipresenti nella vita quotidiana, dalle confezioni di alimenti alle etichette di spedizione. I primi codici a barre monodimensionali, comparsi nel 1974 nel settore della vendita al dettaglio, erano formati da barre verticali di larghezza variabile e memorizzavano un numero a 12 cifre. I codici si sono evoluti con l'aumento della potenza di calcolo e i codici a barre bidimensionali in bianco e nero (codici matrice) sviluppati nei tardi anni '80 hanno segnato l'aumento della densità di dati, da appena poche cifre ad alcune centinaia di byte.
Nel 2003 ho iniziato lavorare per Microsoft Research su un sistema anticontraffazione costituito da una tessera di identificazione biometrica. Era necessario memorizzare, oltre al testo crittografico con il nome e l'età, anche i modelli di scansione di impronta digitale o iride. Per memorizzare tutti i dati necessari, l'attuale codice a barre in bianco e nero avrebbe dovuto avere dimensioni maggiori della stessa tessera d'identità: chiaramente era necessario un nuovo approccio.
Ho dovuto definire come memorizzare più di un bit di informazioni per simbolo, rapporto che costituiva lo standard per codici a barre bidimensionali in bianco e nero. Utilizzando i colori in luogo del bianco e nero, sono riuscito ad aumentare il rapporto a due o tre bit di dati per simbolo grazie, rispettivamente, a quattro e otto colori.
Ho effettuato esperimenti anche con simboli di forme diverse, per verificare se potevano essere compattati più strettamente senza compromettere la registrazione durante la scansione. All'inizio, gli esagoni sembravano una buona opzione, ma le forme si confondevano e il computer non era in grado di distinguerle in modo sufficientemente chiaro.
Alla fine ho scelto i triangoli, perché si intersecano con ordine in uno spazio compresso, pur mantenendo la loro identità di forme distinte. Utilizzando righe di triangoli di più colori, sono riuscito a potenziare la capacità di densità a tre dimensioni.
Le variabili da affrontare erano molte. Una delle sfide principali nel lavorare con i colori è la variazione di specifiche di stampa e condizioni di illuminazione. Sebbene il colore sia facilmente discernibile all'occhio umano (almeno per chi non è daltonico), non è altrettanto facilmente interpretabile da un computer.
Sono stati adottati numerosi approcci diversi per garantire che il software leggesse il colore in modo preciso. Nel codice a barre è stata creata una vera e propria piccola tavolozza, quasi invisibile, che contiene i colori di riferimento esistenti nel codice a barre vero e proprio. Questo sistema rappresenta un meccanismo di calibrazione che specifica esattamente cosa costituisca, ad esempio, un particolare rosso. Sono state sperimentate anche tecniche più avanzate, come algoritmi di clustering dei colori personalizzati e agili che sfruttano la teoria spaziale del colore per categorizzare i colori in serie. Entrambi gli approcci funzionano bene e si integrano alla perfezione.
Una delle finalità di questo progetto era scrivere un programma che consentisse ai telefoni cellulari di leggere i codici a barre. In questo caso è necessario tenere conto di condizioni di scarsa illuminazione e obiettivi fuori fuoco, fissi o a lunghezza focale. Una sfida ulteriore era rappresentata dal realizzare questa visione per computer sulle CPU basate su numeri interi e relativamente lente dei telefoni cellulari; il team doveva quindi elaborare una teoria solida su come rilevare il codice a barre nell'immagine toccando il minor numero possibile di pixel. La scansione avrebbe dovuto funzionare su supporti con un ampio intervallo di qualità di lettura, da brillanti pannelli LCD a fuoco fino a stampe fisiche fuori fuoco e scarsamente illuminate.
L'algoritmo finale decifra le immagini di codici a barre su fotogrammi video della fotocamera in tempo reale, a velocità superiore all'effettiva frequenza di fotogrammi (circa 10 ms su una CPU da 200 Mhz). In un'immagine il numero di pixel minimo da cui può essere costituito un codice a barre per garantire il minor carico utile di dati, ed essere comunque rilevato, è di 45 pixel quadrati.
Far funzionare il tutto in diverse condizioni ha richiesto più di due anni di affinamento. Questa tecnologia è stata recentemente concessa in licenza a terzi e, nel corso di quest'anno, compariranno di certo applicazioni interessanti che se ne avvantaggiano.
Gavin Jancke, Director of Engineering for Microsoft Research, dirige i team Advanced Development Group e Web Experience. In passato ha lavorato come Product Support Engineer, Software Engineer per SQL Server e ha fatto parte del personale addetto alla consulenza tecnica esecutiva di Bill Gates.


Windows Confidential Lavorare sodo o far lavorare il cervello?
Raymond Chen

Per gli sviluppatori di software uno dei grandi vantaggi della Segnalazione errori Windows consiste nel poter ottenere informazioni reali sulle modalità di errore dei propri programmi. Questi report di errore sono disponibili per qualsiasi fornitore di software che si iscriva online a winqual.microsoft.com. Certo, si possono eseguire tutti i generi di test nei propri laboratori, ma c'è sempre un divario tra le condizioni di laboratorio e quelle reali. Ne possono conseguire bug che non compaiono mai durante la fase di test ma che fanno impazzire i clienti.
Alcuni anni fa mi raccontarono la storia di un programmatore al quale era stato assegnato un compito dal proprio team di affidabilità del prodotto. Il team intendeva occuparsi delle cause principali alla base di arresti anomali e blocchi in un componente particolare. Dopo una prima negoziazione, entrambe le parti stabilirono che l'obiettivo era di dimezzare il numero di questo tipo di errori. Il loro intento era quello di correggere i bug responsabili di almeno il 50 percento degli arresti anomali e blocchi nel relativo componente, come quantificato dalla Segnalazione errori Windows.
Tutti sappiamo che le anomalie non sono distribuite in maniera uniforme. Alcune sono rare, altre più comuni e altre ancora sono dilaganti (in termini relativi). L'ingegneria è un gioco di compromessi: risorse limitate (tempo, denaro e capacità intellettive) devono essere assegnate laddove avranno maggior effetto. Poiché lo scopo era ridurre il numero di arresti anomali e blocchi, l'approccio più sensato prevedeva lo studio degli errori più comuni riportati dalla Segnalazione errori Windows per comprenderne le cause principali e tentare poi di risolverli.
Segnalazione errori Windows fornisce informazioni reali sugli errori del programma (Fare clic sull'immagine per ingrandirla)
Quando il programmatore esaminò a fondo i dati di errore, risultò evidente che cinque determinati arresti e blocchi determinavano oltre il 60 percento dei report. Se il programmatore fosse stato in grado di riparare i bug che causavano queste cinque anomalie, avrebbe ridotto il numero di arresti anomali e blocchi di due volte e mezza, superando di gran lunga l'obiettivo di dimezzamento.
L'analisi condotta da Microsoft sui dati relativi alla Segnalazione errori Windows dimostra che il principio di Pareto è una regola empirica sorprendentemente valida per gli arresti anomali e i blocchi di Windows; circa il 20 percento dei bug causa l'80 percento delle anomalie. Lo stesso studio ha rivelato un risultato ancora più sorprendente: solo l'uno percento dei bug causa il 50 percento degli errori. Non tutti i bug sono originati nella stessa maniera ma è una rivelazione vedere quanto sia arcuata la curva di distribuzione.
Dopo aver studiato più attentamente queste cinque anomalie, il programmatore si rese conto la causa alla loro base era la stessa. Gli arresti anomali e i blocchi erano solo manifestazioni diverse dello stesso bug. Pertanto egli sviluppò e testò una correzione e, in collaborazione con i colleghi del controllo qualità, fece quanto necessario per inserirla nella patch successiva. Grazie ad un'unica correzione del bug, la frequenza teorica degli errori per il componente si ridusse immediatamente di due volte e mezza. La missione era compiuta tramite una correzione del codice abbastanza semplice.
Quando ho sentito questa storia, ero stupito dal fatto che la curva di distribuzione degli errori per il componente era ancora più appuntita che per Windows. Ben oltre la metà di tutti gli arresti anomali e blocchi erano causato da un solo bug. Questo genere di analisi del codice non è possibile senza i dati raccolti da uno strumento come Segnalazione errori Windows.
Penserai che il team di affidabilità sarà stato entusiasta di aver conseguito il proprio scopo in così poco tempo. L'obiettivo concordato era stato raggiunto in sole due settimane grazie ad un'unica riparazione. Al contrario, erano furiosi.
"È inaccettabile, pensavamo di impiegarci due mesi. È stato troppo facile!" A quanto pare, volevano che il programmatore lavorasse sodo, anziché far lavorare il cervello.
Sul sito Web di Raymond Chen, The Old New Thing, così come nell'omonimo libro, vengono illustrate la storia di Windows e la programmazione con Win32. Il venti percento dei suoi vestiti sono responsabili dell'ottanta percento del suo bucato.