Creare un'immagine server per un ruolo VM in Windows Azure

Aggiornamento: marzo 2011

[La funzionalità Ruolo VM di Windows Azure verrà ritirata il 15 maggio 2013. Dopo la data di ritiro, le distribuzioni del ruolo VM verranno eliminate. Per continuare a utilizzare le applicazioni esistenti, è possibile utilizzare le Macchine virtuali di Windows Azure. Per ulteriori informazioni sull'utilizzo delle macchine virtuali per l'applicazione in uso, vedere l'argomento relativo al passaggio dal Ruolo VM alle Macchine virtuali di Windows Azure.

Il ruolo VM per Windows Azure è simile agli altri ruoli poiché tutte le istanze del ruolo in esecuzione in Windows Azure sono macchine virtuali in cui viene eseguita una versione del sistema operativo Windows Server. La differenza rispetto al ruolo VM consiste nella creazione e gestione dell'immagine del server. A tal fine, si crea un disco rigido virtuale di base, si installano i componenti di integrazione di Windows Azure e le applicazioni, si effettuano personalizzazioni, si generalizza l'immagine che, successivamente, viene caricata in Windows Azure.

Per creare l'immagine personalizzata di Windows Server 2008 R2 è possibile utilizzare le tecnologie standard di creazione dell'immagine Windows. Ad esempio, è possibile utilizzare la console di gestione di Hyper-V per creare il disco rigido virtuale di base che viene caricato in Windows Azure.

Nel disco rigido virtuale di base sono contenuti il sistema operativo, tutte le personalizzazioni del sistema operativo e le applicazioni. Per creare il disco rigido virtuale di base è possibile utilizzare la console di gestione di Hyper-V. Dopo aver creato e preparato l'immagine server, il disco rigido virtuale viene caricato nel portale di gestione di Windows Azure.

Le informazioni seguenti consentono di approfondire i dischi rigidi virtuali e le immagini server:

Si consiglia di inserire il maggior numero di elementi possibile nel disco rigido virtuale di base. È possibile utilizzare un disco rigido virtuale differenze per applicare le patch e gli aggiornamenti limitati. Gli elementi da inserire nel disco rigido virtuale di base e nel disco rigido virtuale differenze dipendono interamente dall'utente. Poiché il disco rigido virtuale di base e il disco rigido virtuale differenze devono essere considerati come un set tramite cui viene definita l'immagine server, è necessario conservare una copia locale del disco rigido virtuale di base in un percorso sicuro.

Prima di poter caricare il disco rigido virtuale di base in Windows Azure, è necessario installare i componenti di integrazione di Windows Azure. Questi ultimi vengono eseguiti in ogni istanza del ruolo VM creata dall'immagine server e tramite cui viene gestita l'integrazione tra l'istanza del ruolo VM e l'ambiente Windows Azure.

Tramite i componenti di integrazione vengono effettuate le attività necessarie per integrare il sistema operativo dell'istanza del ruolo VM con Windows Azure. Funzionano con il bilanciamento del carico per comunicare informazioni sullo stato delle istanze. Tramite i componenti viene inoltre inizializzata la macchina virtuale installando i certificati e creando le directory di risorse locali in base alle impostazioni della definizione del servizio.

Con Connect di Windows Azure è possibile utilizzare un'interfaccia utente semplice per configurare le connessioni protette tramite IPsec tra computer o macchine virtuali nella rete locale, nonché le istanze dei ruoli in esecuzione in Windows Azure. Tramite IPsec vengono protette le comunicazioni attraverso reti Internet Protocol (IP) grazie all'utilizzo di servizi di sicurezza crittografici. Per ulteriori informazioni sull'utilizzo di Connect di Windows Azure, vedere Connessione di computer locali ai ruoli Windows Azure.

È possibile scrivere un adattatore che viene eseguito durante il processo di installazione o di avvio del sistema operativo. Nel diagramma seguente viene illustrato il modello di sviluppo dell'adattatore:

VMRoleDevelopmentModel

Per scrivere un adattatore sono disponibili due opzioni:

  • È possibile scrivere un adattatore che viene eseguito durante il passaggio di specializzazione. Quest'ultimo è presente durante la configurazione del sistema operativo, dopo il primo caricamento dell'immagine server in Windows Azure oppure dopo la creazione di un'immagine per un'istanza. Questo stile dell'adattatore può essere scritto senza scrivere codice e viene utilizzato uno di due approcci, cioè uno script eseguito dal file di risposte oppure un provider scritto per l'Utilità preparazione sistema (sysprep). Per ulteriori informazioni, vedere l'argomento relativo alla scrittura di un adattatore che viene eseguito durante la configurazione del sistema operativo.

  • È possibile scrivere un adattatore che rappresenta un servizio Windows che viene avviato automaticamente a ogni avvio del sistema operativo. Questo stile dell'adattatore può essere scritto in codice gestito o nativo. Viene utilizzata l'API di runtime del servizio di Windows Azure per raccogliere i dati dinamici nell'ambiente Windows Azure. Per ulteriori informazioni, vedere l'argomento relativo alla scrittura di un adattatore che viene eseguito all'avvio del sistema operativo.

Una differenza principale tra la distribuzione di applicazioni Windows localmente e in Windows Azure consiste nel fatto che quando si carica l'immagine server in Windows Azure, le istanze del ruolo VM create tramite questa applicazione vengono eseguite in un ambiente dinamico. Non è possibile conoscere alcune informazioni essenziali durante la fase di sviluppo, ad esempio quale sarà l'indirizzo IP delle istanze del ruolo VM o il numero delle istanze che saranno in esecuzione e la relativa modalità di indirizzamento. Nel processo di sviluppo di un ruolo VM è inclusa la configurazione delle istanze del ruolo VM e del software installato in modo che vengano eseguiti e comunichino in un ambiente dinamico.

L'immagine server caricata in Windows Azure, insieme al modello del servizio, viene applicata per creare le istanze del ruolo VM. Quando un'istanza del ruolo VM viene portata online per la prima volta, tramite essa devono essere eseguiti tutti i passaggi necessari per preparare l'esecuzione in Windows Azure. Nella maggior parte dei casi, ciò significa che devono essere configurate, e avviate, tutte le applicazioni software installate con le informazioni dinamiche dell'ambiente. Ad esempio, potrebbe essere necessario per scrivere i dati raccolti dall'ambiente dinamico nei file di configurazione dell'applicazione software.

Se tramite un'applicazione i dati vengono scritti in una directory di archiviazione locale, mediante l'istanza del ruolo VM la directory deve essere configurata per l'accesso da parte dell'applicazione. Quando l'immagine server viene innanzitutto caricata per creare l'istanza del ruolo VM, tutte le risorse di archiviazione locale definite nel modello del servizio vengono create come directory locali. La directory locale associata a una risorsa di archiviazione denominata è sicura per impostazione predefinita, cioè è configurata per essere accessibile solo per l'account amministratore. Se tramite l'applicazione verrà richiesta un'operazione di scrittura nella directory, mediante l'istanza del ruolo VM devono essere modificate le autorizzazioni per la directory in modo che sia disponibile per gli account con privilegi più bassi.

Quando l'immagine server viene distribuita in Windows Azure, si trova in uno stato generalizzato, derivante dall'esecuzione dell'Utilità preparazione sistema (sysprep) per preparare l'immagine localmente. Affinché il sistema operativo venga eseguito nell'istanza del ruolo VM in Windows Azure, deve essere sottoposto a un passaggio di specializzazione durante il processo di configurazione. Le informazioni utilizzate per automatizzare questo passaggio di specializzazione sono archiviate nel file di risposte installato nella radice dell'immagine server (c:\unattend.xml) tramite i componenti di integrazione di Windows Azure.

Personalizzando il file di risposte durante la creazione dell'immagine, è possibile eseguire uno script che viene chiamato durante il passaggio di specializzazione dopo che l'immagine è stata caricata in Windows Azure. Per ulteriori informazioni sulla personalizzazione del file di risposte, vedere la pagina relativa a Windows Automated Installation Kit (Windows AIK).

In alternativa, è possibile scrivere un provider sysprep incluso nell'immagine server. Tramite un provider sysprep il relativo strumento viene esteso per includere la funzionalità aggiuntiva definita. I componenti di integrazione di Windows Azure supportano lo strumento sysprep che viene utilizzato per eseguire il passaggio di specializzazione tramite cui viene completata l'installazione di Windows quando l'istanza del ruolo VM viene avviata per la prima volta. Per informazioni dettagliate sulla scrittura di un provider sysprep, vedere la pagina relativa alla guida per gli sviluppatori del provider preparazione sistema (Sysprep) per Windows 7.

Un adattatore di questo tipo viene eseguito solo durante la prima sequenza di avvio per l'istanza e non quando quest'ultima viene riavviata. Una limitazione di questo stile di adattatore è l'impossibilità di rispondere automaticamente alle modifiche apportate alle impostazioni di configurazione del servizio. Se le modifiche alle impostazioni di configurazione devono essere applicate dall'adattatore all'istanza, tramite l'operatore dovrà essere ricreata manualmente l'immagine dell'istanza in modo da eseguire l'adattatore e applicare le nuove impostazioni. Se l'applicazione si basa su impostazioni di configurazione che potrebbero dover essere modificate durante il ciclo di vita dell'immagine server, provare a scrivere l'adattatore come servizio Windows.

Un adattatore può essere scritto come servizio Windows che viene avviato automaticamente insieme a Windows e in cui viene utilizzata l'API di runtime del servizio di Windows Azure per raccogliere i dati dinamici da Windows Azure. Potrebbe essere necessario scrivere un servizio Windows se occorre disporre di informazioni sull'indirizzo di rete per l'istanza del ruolo VM corrente o per altre istanze del ruolo in esecuzione nel servizio, se è necessario scrivere in una risorsa di archiviazione locale oppure se occorre leggere le impostazioni di configurazione del servizio in fase di esecuzione o rispondere quando vengono modificate.

Il servizio Windows deve essere un processo di Windows a 64 bit per poter utilizzare l'API di runtime del servizio. Può essere scritto in codice gestito o nativo. Per informazioni sull'API, vedere Windows Azure Managed Library Reference e Windows Azure Native Library Reference.

L'API di runtime del servizio può essere chiamata solo da un processo in esecuzione con un account amministratore o LocalSystem. Tramite questa restrizione viene garantito che il servizio sia sicuro per impostazione predefinita, eliminando il rischio di un processo con privilegi bassi in cui l'API di runtime del servizio viene utilizzata per leggere le impostazioni di configurazione del servizio.

Il servizio Windows deve essere configurato in modo che venga avviato automaticamente insieme a Windows. Tramite esso devono essere implementati i metodi del ciclo di vita della classe ServiceBase, inclusi OnStart e, se è necessaria una sequenza di arresto, OnStop o OnShutdown. Il codice di avvio deve essere completo prima della restituzione da parte del metodo OnStart. Tutte le sequenze di arresto richieste dal servizio Windows devono essere completate prima della restituzione da parte di OnStop o OnShutdown. Per ulteriori informazioni sulla scrittura di servizi Windows, vedere Applicazioni di servizio Windows.

Una volta avviati tutti i servizi di avvio automatico, incluso l'adattatore, tramite Windows Azure viene riconosciuto che l'istanza è pronta a ricevere il traffico dal bilanciamento del carico. Per questo motivo, è importante verificare che l'adattatore abbia effettuato tutte le attività necessarie per preparare l'istanza del ruolo VM e qualsiasi software in esecuzione prima del completamento del metodo OnStart. L'istanza del ruolo VM deve trovarsi in uno stato pronto dal momento in cui la sequenza di avvio viene completata fino all'avvio della sequenza di arresto, a meno che l'istanza non venga esclusa esplicitamente dalla rotazione impostando il relativo stato su Busy. Questa operazione può essere effettuata aggiungendo un gestore eventi all'evento StatusCheck. In occasione della generazione dell'evento, il metodo SetBusy può essere chiamato sull'oggetto dell'argomento dell'evento. Per modificare lo stato dell'istanza del ruolo VM, è inoltre possibile utilizzare il cmdlet di PowerShell Set-RoleInstanceStatus.

Dopo aver installato i componenti di integrazione di Windows Azure, si installano le applicazioni e si apportano tutte le modifiche di configurazione del sistema operativo necessarie; se si desidera, si installa l'agente di Connect di Windows Azure, si crea e si installa un adattatore e, successivamente, è necessario preparare l'immagine da caricare.

Affinché il disco rigido virtuale venga caricato correttamente in Windows Azure, è necessario procedere alla generalizzazione dell'immagine server tramite il comando Sysprep. Per ulteriori informazioni sull'utilizzo di Sysprep, vedere la pagina relativa all'introduzione all'utilizzo di Sysprep. Per ulteriori informazioni sul caricamento del disco rigido virtuale, vedere Caricare un disco rigido virtuale per un ruolo VM in Windows Azure.

Vedere anche

Aggiunte alla community

Mostra: