Esporta (0) Stampa
Espandi tutto

Pianificazione di una migrazione ad Azure

Aggiornamento: aprile 2014

Quando si inizia a pianificare la migrazione, è necessario prendere in considerazione diversi fattori chiave quali costo, requisiti aziendali e tecnici, sequenza temporale ed eventuali test necessari nel processo di migrazione. In questa sezione vengono illustrate in dettaglio diverse problematiche e procedure che è consigliabile tenere presenti quando si pianifica la migrazione ad Azure:

Autori: Steve Howard
Revisori: James Podgorski, Paolo Salvatori, Selcin Turkarslan, Stuart Ozer

Il costo è una delle questioni più importanti che è necessario affrontare. È consigliabile valutarlo all'inizio del processo decisionale e di pianificazione se si intende eseguire la migrazione di un'applicazione locale ad Azure. La determinazione dei prezzi di un'applicazione per Azure dipende da vari fattori, quali il carico del traffico di rete, le caratteristiche di input/output dell'applicazione e il volume di dati elaborati dall'applicazione. Il calcolo del prezzo non rientra nell'ambito di questo argomento. Si consiglia di utilizzare il calcolatore dei prezzi di Azure per effettuare una stima del costo all'inizio della pianificazione della migrazione. Il calcolatore dei prezzi di Azure è disponibile qui.

Quando si calcola il costo per la propria organizzazione, includere i costi diretti di Azure durante lo sviluppo e il test. In un progetto di sviluppo locale l'utente paga per i server di sviluppo e di test. Analogamente, nell'ambiente Azure è necessario pagare per le risorse che vengono utilizzate durante lo sviluppo e il test. Inoltre, l'utente deve calcolare i costi di formazione e quelli associati alla portabilità dell'applicazione ad Azure. Si consiglia di eseguire in anticipo test delle prestazioni e attività di pianificazione della capacità per valutare la capacità necessaria per l'applicazione.

Tramite Azure è possibile soddisfare in modo ottimale alcuni requisiti aziendali e tecnici. Anche se questo elenco non è esaustivo, le applicazioni con queste caratteristiche sono candidate ottimali per la migrazione ad Azure:

  • Base utente distribuita: i data center di Azure sono posizionati in diversi continenti. L'interconnessione tra i data center rende possibile una distribuzione dei dati a elevate prestazioni, se necessario. Grazie a funzionalità di Azure quali i servizi per la rete CDN e per la sincronizzazione dati, la distribuzione dei dati di maggiore utilizzo o importanti è garantita tra data center vicini agli utenti finali. Con utenti che accedono ai data center vicini alla relativa area geografica si riduce la durata di un round trip, ottimizzando di conseguenza l'esperienza utente.

  • Carico variabile: è necessario acquistare hardware per applicazioni locali per la gestione dei picchi di carico. Ad esempio, un punto vendita acquista in genere server mediante i quali è possibile gestire il carico per gli acquisti dei periodi festivi. Analogamente, un reparto di contabilità può pianificare un'infrastruttura aggiuntiva per poter gestire i carichi massimi nei cicli i chiusura di fine mese o di fine anno. In tutti gli altri periodi i server destinati alla gestione di carichi massimi di questo tipo sono sottoutilizzati. D'altro canto, nelle applicazioni progettate per una scalabilità elastica è possibile utilizzare Azure per portare online le nuove istanze di applicazioni durante i periodi di massima attività e tornare a livelli di capacità e potenza di elaborazione più bassi in periodi di attività inferiori. In questo modo, tramite Azure l'utente può, con applicazioni correttamente progettate e gestite, pagare solo ciò di cui necessita.

  • Multi-tenancy: in caso di provider di servizi, Azure offre diverse modalità per fornire i servizi dell'applicazione a qualsiasi numero di clienti nella stessa infrastruttura, riducendo di conseguenza i costi operativi.

  • Concentrazione sulle applicazioni: i provider di servizi desiderano concentrare le proprie risorse in particolare sullo sviluppo di applicazioni e funzionalità, piuttosto che sulla gestione dell'infrastruttura. Tramite Azure è possibile eliminare buona parte del carico amministrativo richiesto dall'infrastruttura in cui sono ospitate applicazioni locali o applicazioni server ospitate tradizionali. In questo modo l'utente può concentrare le risorse sullo sviluppo di applicazioni e funzionalità.

  • Riduzione dei requisiti delle risorse dell'infrastruttura: quando si progettano applicazioni per poter sfruttare i vantaggi offerti dalla scalabilità elastica offerta da Azure, anche le istanze di ruoli e risorse possono essere allocate in base alle esigenze. Non vi sono investimenti hardware iniziali da effettuare né esiste la necessità di mantenere server in grado di gestire carichi massimi in periodi di basso utilizzo.

In Azure, come vantaggio orientato al servizio, oltre alla piattaforma tradizionale è possibile ospitare macchine virtuali. Tramite queste macchine è possibile eseguire qualsiasi sistema operativo supportato da Azure. Inoltre, è possibile eseguire applicazioni nelle stesse modalità con cui verrebbero eseguite in locale. Per un elenco dei sistemi operativi supportati, vedere Panoramica delle macchine virtuali di Azure. Inoltre, queste macchine virtuali possono far parte di un'architettura dell'applicazione più ampia in cui potrebbero essere inclusi istanze di ruoli Web o di lavoro ed altri componenti di Azure. Le macchine virtuali rappresentano una modalità per trasferire alcuni servizi o alcune parti dell'applicazione che, altrimenti, non sarebbero facilmente trasferibili ad Azure. Per ulteriori informazioni, vedere Migrazione con le macchine virtuali di Windows Azure.

Nella fase di analisi e progettazione è consigliabile identificare le applicazioni che offriranno all'utente maggiori vantaggi con lo spostamento in Azure. Successivamente, cominciare a progettare l'implementazione di Azure e il piano di implementazione. Durante questa fase, è consigliabile pianificare la struttura della progettazione dell'architettura e della sequenza temporale.

Alcuni degli elementi chiave della pianificazione sono:

  • Identificazione delle sfide correnti: nell'elenco riportato di seguito vengono illustrati alcuni esempi di sfide che devono essere identificate durante la pianificazione di eventuali esigenze di riprogettazione:

    • Componenti dell'applicazione che non vengono eseguiti in base allo standard più elevato con i carichi correnti nell'architettura attuale: se, ad esempio, una query SQL non viene eseguita correttamente, è consigliabile ottimizzarla prima di eseguire la migrazione o un'ulteriore progettazione. Inoltre, è consigliabile riprogettare ed eseguire la scalabilità orizzontale di tutti i componenti a livello applicazione.

    • Determinazione dei requisiti della scalabilità elastica: è consigliabile identificare la modalità di scomposizione dell'applicazione in unità funzionali, scalabili in modo indipendente, eseguibili separatamente l'una dall'altra.

    • Modelli di carico non uniformi: è consigliabile identificare i modelli di carico non uniformi e progettare l'applicazione per la scalabilità orizzontale in modo da gestire i periodi di massima attività. Si consiglia di preparare dei piani sulla modalità di gestione del livello di scalabilità orizzontale da periodi di attività massima a periodi di richiesta bassi.

    • Proiezioni di crescita: spesso le proiezioni di crescita sono il primo elemento tramite cui viene segnalato al reparto IT la necessità di una modifica di paradigma. Decidere il punto in cui la scalabilità orizzontale può essere una soluzione per valutare le proiezioni di crescita. Queste ultime, inoltre, possono indicare la necessità di considerare i cambiamenti del paradigma, ad esempio il passaggio a un paradigma di analisi di dati di grandi dimensioni in determinate applicazioni incentrate su data warehouse. Nella fase di pianificazione è consigliabile discutere di queste opzioni. Si potrebbe non essere in grado di conoscere con certezza la soluzione fino a un successivo processo di progettazione e implementazione. È consigliabile elencare contingenze di questo tipo e determinare i fattori in modo da poterli valutare al momento opportuno, ad esempio durante la migrazione iniziale o in un momento successivo.

  • Identificazione dei requisiti tecnici: conoscere i requisiti di ciascun componente dell'applicazione sia nei periodi di massima attività sia in quelli di minore attività.. Successivamente, pianificare la scala per ogni componente. La capacità e il meccanismo di applicazione della scala di ogni componente possono essere diversi. I requisiti tecnici non possono essere solo le prestazioni. In caso di pianificazione di una migrazione, ad esempio, i requisiti di disponibilità elevata e di ripristino di emergenza oppure quelli per la latenza di rete massima dovrebbero essere determinati e confrontati con funzionalità di Azure. Nell'elenco seguente vengono illustrati alcuni esempi di requisiti tecnici:

    • Utilizzo dell'archiviazione relazionale: esaminare i dati archiviati nei database relazionali. I dati che sono realmente transazionali e relazionali o per i quali è richiesta veramente l'elaborazione transazionale devono rimanere nell'archivio relazionale. Per archiviare questo tipo di dati, è possibile utilizzare un database SQL di Azure (database SQL) o SQL Server in esecuzione nelle macchine virtuali. L'altro tipo di dati può essere archiviato in modo efficiente nelle tabelle e nell'archiviazione BLOB di Azure o in unità Azure. Si consiglia di identificare il tipo di archiviazione necessario per ogni parte dei dati.

    • Scelta dell'archiviazione di dati relazionali: la scelta del database SQL o di SQL Server in esecuzione nelle macchine virtuali di Azure dipende da diversi fattori. Se si desidera evitare il carico amministrativo di disponibilità elevata, il bilanciamento del carico e il failover trasparente, il database SQL è la scelta migliore. Tuttavia, per uno stato intermedio durante l'esecuzione della migrazione di un'applicazione o per casi speciali per cui non sono ancora disponibili funzionalità nel database SQL, la soluzione migliore potrebbe essere SQL Server in esecuzione nelle macchine virtuali di Azure. Le risposte a queste domande dipendono dalla situazione e dalla soluzione. Nell'elenco seguente vengono illustrate alcune considerazioni in merito:

      • Dimensioni del database: il limite in termini di dimensioni dei database SQL di Azure è attualmente pari a 5 GB di dati per il database dell'edizione Web e di 150 GB di dati per il database dell'edizione aziendale. Per ampliare la capacità del database, utilizzare un metodo di scalabilità orizzontale. Per informazioni sui metodi di scalabilità orizzontale di Azure, leggere "Scalabilità orizzontale di database SQL di Azure". Per le informazioni più aggiornate sulle edizioni e sulle dimensioni di database disponibili, vedere Account e fatturazione nel database SQL di Azure.

      • Numero di database: per impostazione predefinita, il database SQL supporta fino a 6 server per sottoscrizione e 150 database in ogni server di database SQL, incluso il database master. Questo limite può essere esteso. Per ulteriori informazioni, contattare un rappresentate del Supporto tecnico presso il Portale per i clienti dei Microsoft Online Services.

      • Query tra database: il database SQL non supporta attualmente i join tra database o altre query tra database. Se si dispone di unioni o join per i quali vengono richiesti più database nel database SQL, è necessario applicare quella logica nel livello applicazione dell'applicazione in uso.

      • Oggetti Common Language Runtime (CLR): il database SQL attualmente non supporta stored procedure, aggregazioni, trigger o funzioni CLR. È consigliabile trasferire le stored procedure, i trigger o le funzioni in Transact-SQL per l'esecuzione nel database SQL. La logica complessa o le operazioni, ad esempio le aggregazioni, che non possono essere eseguite in Transact-SQL a livello del database devono essere spostate al livello applicazione. Un'attività di questo tipo può essere effettuata utilizzando un ruolo di lavoro.

      • Tipi di dati: il database SQL non offre supporto per alcuni tipi di dati di sistema di SQL Server. Per le informazioni più aggiornate, vedere Tipi di dati (database SQL di Azure) in MSDN Library di SQL.

      • Replica: i tipi di replica, ad esempio quella transazionale o quella di tipo merge, non sono disponibili nel database SQL, ma possono essere configurate ed eseguite in SQL Server in esecuzione in macchine virtuali di Azure. È possibile utilizzare la sincronizzazione dati SQL per sincronizzare i dati tra istanze del database SQL. Tuttavia, è possibile che il servizio sincronizzazione dati SQL non rappresenti la soluzione ottimale laddove sono richieste coerenza transazionale o risoluzioni di conflitti complesse. Avviso: la sincronizzazione dati SQL è attualmente disponibile solo come anteprima ai fini esclusivi di valutazione del prodotto per le versioni successive e non deve essere utilizzato in ambienti di produzione.

      • Ricerca full-text: il database SQL di Azure attualmente non supporta la funzionalità di ricerca full-text. Se tramite l'applicazione vengono eseguite query full-text in dati di tipo carattere nelle tabelle di SQL Server, è possibile considerare l'esecuzione della migrazione del database a SQL Server in una macchina virtuale di Azure. Per ulteriori informazioni su SQL Server in una macchina virtuale di Azure, vedere l'argomento Migrazione a SQL Server in una macchina virtuale di Azure.

      • Licenze: l'addebito del database SQL viene effettuato mensilmente in base alle dimensioni del database definite. Quando SQL Server è in esecuzione in una macchina virtuale di Azure, è richiesta una licenza.

      • Accesso e sicurezza: l'autenticazione di Windows (sicurezza integrata) non è supportata nel database SQL, tuttavia è disponibile per SQL Server in esecuzione nelle macchine virtuali di Azure. Per ulteriori linee guida e limitazioni sulla sicurezza del database SQL, vedere Linee guida e limitazioni per la sicurezza per il database SQL di Azure.

      • Analogie nelle funzionalità: per ulteriori informazioni su analogie e differenze tra SQL Server e il database SQL, vedere SQL Database Overview.

  • Accesso e sicurezza utente: con i nuovi miglioramenti di rete apportati ad Azure, è possibile estendere a questo servizio un dominio Active Directory della rete locale. Per ulteriori informazioni, vedere Migrazione con le macchine virtuali di Windows Azure. Per informazioni dettagliate sull'amministrazione della sicurezza del database SQL, vedere Gestione di database e account di accesso in database SQL di Azure.

  • Scomposizione funzionale dell'applicazione: identificare il punto in cui l'applicazione può essere suddivisa in unità funzionali in modo che possa essere eseguita in macchine virtuali o ruoli Azure separati. È possibile eseguire questa operazione per creare una scala elastica e prendere in considerazione l'uso di applicazioni ibride, qualora alcune applicazioni non siano appropriate per il cloud computing.

  • Standard PCI (Payment Card Industry) e altri requisiti normativi: prima di spostare un'applicazione o un componente in Azure, verificare lo stato corrente delle certificazioni richieste o dei requisiti. In casi quali i requisiti di conformità PCI, è possibile rimuovere alcune parti dell'applicazione e del database dall'elemento migrato ad Azure ed eseguire un'applicazione ibrida. In questo modo, vengono offerti i vantaggi di Azure e del calcolo cloud nella maggior parte dei componenti e, al contempo, il rigido controllo istituzionale e la conformità per le parti dei dati e dell'applicazione per cui è richiesta.

  • Componenti principali che non possono essere ospitati nella piattaforma Azure: può non essere possibile ospitare alcuni componenti o alcuni tipi di dati nel cloud pubblico a causa di altre problematiche. Identificare questi componenti e considerare l'utilizzo di un'applicazione ibrida. In caso di architettura ibrida, è possibile ospitare alcuni componenti in Azure per rendersi conto del vantaggio completo di Azure e del cloud computing. Contemporaneamente, è ancora possibile ottenere il controllo istituzionale rigido e la conformità per le parti dei dati e dell'applicazione per cui è richiesta.

Una volta definito l'ambito della migrazione, anche la quantità di lavoro per ogni passaggio nel piano della migrazione diventa chiara. Esaminare ogni applicazione e componente dati e stimare il tempo e le risorse necessarie per lo sviluppo, il test e la migrazione. Quando dal punto di vista funzionale si scompone l'applicazione, sviluppare in parallelo i componenti scomposti per creare componenti scalabili in modo elastico.

Stabilire i punti cardine del progetto, ad esempio i test funzionali e delle prestazioni, e le date di rilascio nel piano di migrazione. La migrazione può continuare con una serie di passaggi e iterazioni quando componenti diversi sono pronti per Azure o quando i componenti sono pronti per essere spostati in ruoli Web o di lavoro Azure.

Quando viene impostata la sequenza temporale per lo sviluppo e la migrazione, pianificare la crescita in quel periodo di tempo e decidere le operazioni da eseguire per l'applicazione e l'infrastruttura esistenti. Questo tipo di pianificazione consente all'utente di utilizzare il sistema esistente fino al completamento della migrazione. Durante lo sviluppo del piano provvisorio, identificare i punti deboli correnti, le operazioni da eseguire per consentire attività continuative e quali operazioni di scala possono continuare nell'infrastruttura provvisoria. Inoltre, identificare i passaggi che potrebbero essere necessari per consentire le attività continuative. Spesso questi passaggi possono essere semplici quanto l'ottimizzazione di una query SQL o l'aggiunta di un server Web a seconda delle caratteristiche della particolare applicazione in uso. Identificare piani di emergenza in caso di crescita più veloce del previsto o picchi imprevisti. Quando si preparano i piani di emergenza, considerare se eventuali crescite o picchi possono essere gestiti tramite la scalabilità orizzontale in Macchine virtuali di Azure, dal momento che in questo modo è possibile gestire situazioni di questo tipo senza investimenti hardware aggiuntivi.

In qualsiasi piano di migrazione devono essere inclusi piani per i test di funzionalità e di carico completi. Una descrizione delle metodologie di test non rientra nell'ambito di questo articolo. Nell'elenco seguente vengono illustrati alcuni punti critici da ricordare durante il test:

  • Automatizzazione degli script di test

  • Test di tutti i livelli e componenti dell'applicazione

  • Testi sui rapporti di attività che rappresentano i rapporti reali nei sistemi in uso

  • Test a un livello di utilizzo massimo previsto o oltre

Si consiglia di includere il tempo per i test di compilazione e di esecuzione, nonché il tempo di correzione dei problemi riscontrati dal test.

Quando si definiscono i requisiti aziendali e tecnici, identificare le risorse necessarie per eseguire correttamente la migrazione. Potrebbe essere necessario introdurre questi elementi per la migrazione. Vi sono tre aree principali da esaminare quando si identificano le risorse:

  • Personale: può essere necessario introdurre altri dipendenti con set aggiuntivi di competenze al fine di eseguire correttamente la migrazione dell'applicazione. Inoltre, dopo la migrazione, è possibile che i ruoli del personale tecnico vengano modificati e che per le competenze sia necessario un aggiornamento. Si considerino, ad esempio, i ruoli dell'amministratore dell'account e degli amministratori del servizio per gestire gli account di accesso, l'accesso e il servizio e i livelli di scala.

  • Strumenti: identificare gli strumenti necessari per sviluppare, testare e distribuire l'applicazione Azure. Per ulteriori informazioni, vedere Strumenti di Azure per Microsoft Visual Studio e Supporto per strumenti e utilità del database SQL di Azure.

  • Consulenza: può essere necessaria un'abilità specifica per eseguire la migrazione dell'applicazione. Uno specialista della migrazione può far risparmiare tempo e denaro preziosi consentendo di evitare trappole comuni.

In caso di applicazioni di piccole dimensioni, il portale di gestione di Microsoft Azure può essere sufficiente per gestire le distribuzioni di Azure. Tramite questo portale è possibile accedere e gestire le distribuzioni e le applicazioni, nonché modificare il numero di ruoli dell'istanza e gestire le istanze del database SQL. Tuttavia, in caso di applicazioni complesse e applicazioni tramite cui viene offerto un servizio ai clienti, è possibile che il portale di gestione di Microsoft Azure non sia sufficiente.

Tramite l'API REST esposta da Azure l'utente può gestire a livello di codice le applicazioni e le macchine virtuali ospitate in Azure, nonché il provisioning e l'utilizzo dell'archiviazione Azure. È possibile scrivere un'interfaccia di gestione per gestire la scala e il monitoraggio dell'ambiente Azure. È consigliabile che nel piano di migrazione sia incluso un piano per gestire l'applicazione dopo la migrazione, specialmente se questa gestione consiste nell'includere un'interfaccia personalizzata o un'automazione.

Per ulteriori informazioni sull'API REST per la gestione delle distribuzioni di Azure, vedere i riferimenti all'API per Azure.

Vedere anche

Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft