Esporta (0) Stampa
Espandi tutto

Implementazione del piano di migrazione per Azure

Aggiornamento: aprile 2014

Azure è una piattaforma di servizi e di calcolo su scala Internet ospitata nei data center di Microsoft. Tramite Azure gli sviluppatori e gli amministratori non devono implementare l'infrastruttura del software e dell'hardware sottostante poiché tutte le risorse relative al sistema operativo sottostante, all'hardware, alla rete e all'archiviazione, nonché gli aggiornamenti della piattaforma vengono monitorati automaticamente da Microsoft.

Dopo aver eseguito la migrazione dell'applicazione al cloud è consigliabile eseguire i test funzionali e delle prestazioni nell'applicazione, esattamente come avviene per qualsiasi nuova applicazione appena distribuita. Dal momento che Azure è diverso dalla piattaforma locale, quando si implementa la migrazione è necessario prendere in considerazione i seguenti aspetti importanti:

Si noti che in questo argomento vengono descritti soprattutto i servizi cloud di Azure. Per linee guida introduttive sulla migrazione con SQL Server nelle macchine virtuali di Azure, vedere Migrazione con le macchine virtuali di Windows Azure.

Autori: Kun Cheng, Steve Howard
Collaboratore: Selcin Turkarslan

Durante la migrazione delle applicazioni al cloud, è necessario sapere come eseguire il test e il debug dell'applicazione in modo da essere sicuri che il funzionamento nel cloud sia quello previsto. Di seguito è riportato un elenco di approcci utilizzabili per testare l'applicazione:

  • Strumenti di Azure per Microsoft Visual Studio: consente di creare l'applicazione e quindi eseguirla o effettuarne il debug localmente utilizzando gli emulatori di calcolo e di archiviazione forniti tra gli strumenti di Azure. Consente di sviluppare l'applicazione localmente prima di pubblicarla in Azure. Tramite gli strumenti di Azure per Microsoft Visual Studio viene esteso Visual Studio 2010 ed è possibile testare l'applicazione con emulatori di calcolo e di archiviazione tramite cui viene fornita la maggior parte delle funzioni di Azure. È consigliabile effettuare questo tipo di test nelle fasi iniziali del test funzionale. Per ulteriori informazioni, vedere Strumenti di Azure per Microsoft Visual Studio.

  • SQL Server Data Tools: offre un ambiente integrato all'interno di Visual Studio 2010 che è possibile utilizzare per progettare database, creare o modificare oggetti e dati di database oppure eseguire query per tutte le piattaforme SQL supportate, inclusi il database SQL di Azure remoto e Microsoft SQL Server 2012 locale. Consente di testare le soluzioni del progetto di database tramite il database predefinito locale o il database SQL di Azure esaminando la parte di accesso ai dati relazionali dell'applicazione. Per ulteriori informazioni, vedere SQL Server Data Tools. Nota: tramite gli strumenti di Azure per Microsoft Visual Studio e SSDT è possibile effettuare i test di funzionalità e di compatibilità di base nell'applicazione con origini dati offline e online. Per testare tutti gli aspetti di un'applicazione cloud reale in termini di funzionalità, prestazioni e scalabilità, è necessario effettuare un test di simulazione in Azure in cui l'applicazione viene distribuita ed è in esecuzione.

  • Framework di test automatico: in molte applicazioni esistenti è già presente un framework di test automatico che può essere utilizzato per assicurarsi che tutti i componenti o le funzioni dell'applicazione funzionino come previsto. Quando un'applicazione viene eseguita in Azure, il funzionamento del framework di test automatico dipende dalla relativa progettazione. Il funzionamento del framework di test automatico potrebbe essere assicurato se questo elemento deve essere eseguito da istanze locali, ma può essere connesso a un'applicazione in Azure utilizzando gli endpoint definiti. In caso contrario, è consigliabile ospitare sia il framework di test automatico sia l'applicazione in Azure per attenuare eventuali problemi di perdita di connessione e di latenza.

  • Test di carico di Visual Studio: se in un'applicazione non è disponibile alcun framework di test automatico, è consigliabile crearne uno nuovo e utilizzare il test di carico di Visual Studio per effettuare un test di simulazione con più utenti simultanei.

Tra le fasi di test, gestione temporanea e produzione, è consigliabile provare a ridurre il più possibile l'attuale tempo di trasferimento. Per la copia di un database di grandi dimensioni dall'istanza locale in Azure potrebbero essere richieste molte ore o giorni. Inoltre, è improbabile che si desideri che l'applicazione rimanga inattiva per tutto il tempo necessario per eseguire la migrazione totale dei dati esistenti. Per questo motivo è necessario predisporre un piano per ridurre qualsiasi tempo di inattività causato dal trasferimento. Si noti che nel concetto di trasferimento è incluso il tempo necessario per eseguire lo spostamento finale in Azure. Prima di effettuare il trasferimento, esaminare le tabelle e decidere in quali sono contenuti dati statici e in quali sono inclusi dati che potrebbero cambiare durante il trasferimento. Per quanto riguarda i dati statici, non si deve spostare alcun dato durante la fase di trasferimento. Tuttavia, se non si è sicuri che i dati di una particolare tabella possano cambiare durante il trasferimento, è consigliabile includere nel sistema la logica per eseguire la migrazione di tutte le modifiche in un secondo momento. Si consiglia inoltre di valutare se è necessario eseguire la migrazione di tutti i dati dai sistemi locali al cloud prima di pubblicare l'applicazione in Azure. Se l'applicazione può essere pubblicata e i dati possono essere aggiornati successivamente, è possibile eliminare qualsiasi tempo di inattività.

Tuttavia, se i dati in Azure devono essere coerenti con i dati locali prima di essere pubblicati in Azure, è consigliabile ridurre, in fase di trasferimento, la quantità di dati che deve essere sottoposta a migrazione in modo da diminuire il tempo di inattività necessario per il trasferimento effettivo. In alcuni casi, potrebbe essere utile spostare alcuni dati prima del trasferimento e, successivamente, spostare i dati rimanenti dopo il trasferimento effettivo. In questi casi, nel piano di migrazione devono essere identificati chiaramente i dati che devono essere sottoposti per primi alla migrazione, nonché i dati rimanenti la cui migrazione può essere eseguita dopo il trasferimento. In questo modo l'applicazione può essere pubblicata in Azure con un minor tempo di inattività poiché l'applicazione può essere in produzione mentre si esegue la migrazione dei dati rimanenti. Per eseguire la migrazione prima del trasferimento è possibile utilizzare i seguenti metodi di sincronizzazione dei dati:

Il servizio Sincronizzazione dati SQL (anteprima) offre funzionalità di sincronizzazione dei dati per i database SQL, ossia SQL Server e Database SQL. Il servizio attualmente presenta due funzionalità principali:

  • Sincronizzazione dei dati tra database di SQL Server locali e istanze di di Database SQL, che consente alle applicazioni locali e basate sul cloud di utilizzare dati identici.

  • Sincronizzazione dei dati tra due o più istanze di di Database SQL. Le istanze possono trovarsi nello stesso data center, in data center diversi o in aree diverse.

Sincronizzazione dati SQL (anteprima) è uno strumento utile per sincronizzare i database locali e le istanze del Database SQL di nelle seguenti situazioni:

  • È necessario effettuare un test parallelo delle applicazioni.

  • È necessario eseguire l'applicazione in parallelo prima dello spostamento finale di tutte le operazioni sui dati locali in .

  • Durante la migrazione a , è necessario eseguire l'applicazione in locale e, contemporaneamente, è richiesto un tempo di inattività minimo.

  • È necessario effettuare la sincronizzazione dati continua all'interno di una soluzione ibrida tra l'istanza locale e l'applicazione .

Si noti che per tenere traccia delle modifiche dei dati incrementali, durante la configurazione della sincronizzazione tramite Sincronizzazione dati SQL (anteprima) viene aggiunta una tabella di rilevamento delle modifiche per ogni tabella che viene sincronizzata. Quando si utilizza Sincronizzazione dati SQL (anteprima), assicurarsi che nei piani di spazio si tenga conto delle tabelle di rilevamento delle modifiche. Inoltre, è consigliabile non apportare modifiche alle strutture delle tabelle o alle chiavi primarie delle tabelle che vengono sincronizzate dopo la configurazione della sincronizzazione, a meno che il gruppo di sincronizzazione non venga nuovamente inizializzato. Sincronizzazione dati SQL (anteprima) non è ottimale nelle situazioni in cui è necessaria la sincronizzazione dati intermedia o continua.

Avviso: Sincronizzazione dati SQL (anteprima) è attualmente disponibile come anteprima ai fini esclusivi di valutazione del prodotto per versioni successive e non deve essere utilizzata in ambienti di produzione.

Per ulteriori informazioni su Sincronizzazione dati SQL (anteprima), vedere Sincronizzazione dati SQL (anteprima).

È possibile utilizzare la replica, il mirroring o il log shipping per spostare i dati da un'istanza di SQL Server locale a un'altra istanza di SQL Server locale o a un'istanza di SQL Server in esecuzione in una macchina virtuale di Azure. Tuttavia, queste operazioni non possono essere utilizzate per spostare i dati all'interno o all'esterno di un database SQL di Azure. Per ulteriori informazioni, vedere Log shipping e replica e Mirroring del database e log shipping.

Per ridurre il tempo necessario per spostare i dati in fase di trasferimento, è consigliabile spostare la maggior quantità di dati possibile nella piattaforma Azure prima del trasferimento effettivo. È possibile creare un processo ETL personalizzato per spostare i dati modificati dal sistema locale all'ambiente Azure. In caso di migrazione da istanze locali di SQL Server 2008 o versioni successive, è consigliabile utilizzare Change Data Capture o il rilevamento delle modifiche ai dati per assicurarsi che vengano spostati solo tutti i dati modificati dal database locale all'istanza del database SQL di Azure. Per ulteriori informazioni su queste due funzionalità, vedere Rilevare le modifiche ai dati nella documentazione online di SQL Server. Per i database in cui non viene utilizzato Change Data Capture o il rilevamento delle modifiche ai dati, è necessario creare un sistema di rilevamento per le modifiche e per i dati di cui è stata eseguita la migrazione. In tutti i casi, per ridurre il tempo di inattività richiesto per il trasferimento effettivo è necessario che la quantità di dati da spostare in fase di trasferimento effettivo sia minima.

Utilizzando l'applicazione livello dati è possibile esportare i dati da un'istanza di SQL Server e posizionarli nell'archiviazione BLOB di Azure da cui possono essere importati in un database SQL di Azure. Con l'applicazione livello dati è possibile configurare filtri in base a cui le tabelle possono essere importate o esportate, ma non filtri a livello di riga. Per questo motivo, l'applicazione livello dati è appropriata nei casi in cui tabelle intere rientrano in un unico database, mentre non è adatta per i database con scalabilità orizzontale. L'applicazione livello dati non è ottimale per la migrazione dei dati per le applicazioni in cui è necessaria la sincronizzazione dati continua. Per ulteriori informazioni, vedere Esportazione di un'applicazione livello dati nella documentazione online di SQL Server.

Grazie alla creazione di backup del database è possibile evitare la perdita di dati causata da errori amministrativi, dell'applicazione o dalla perdita totale di un data center. Il backup e il ripristino dei dati sono diversi nel database SQL di Azure rispetto a un'istanza di SQL Server locale e devono funzionare con le risorse e gli strumenti disponibili. Per un utilizzo affidabile delle funzionalità di backup e ripristino è pertanto necessaria un'apposita strategia per il database SQL di Azure. Esistono tre categorie generali di problemi che potrebbero dover essere risolti in un'istanza del database SQL di Azure:

  • Errori hardware o dell'infrastruttura: all'interno di un data center si possono verificare errori hardware. Ad esempio, potrebbe verificarsi l'arresto anomalo del nodo fisico in cui viene eseguita l'istanza del database SQL di Azure.

  • Problemi o errori dell'applicazione o generati dall'utente: utenti o applicazioni possono apportare modifiche indesiderate ai dati. che richiedano un'operazione di ripristino. Ad esempio, è possibile che un utente modifichi determinati dati che appartengono al cliente sbagliato e così via.

  • Perdita delle funzionalità del data center: nell'attuale contratto di servizio del database SQL di Azure è presente un'eccezione per fattori esterni al ragionevole controllo di Microsoft, ad esempio le calamità. In caso di calamità, il data center potrebbe essere danneggiato a tal punto che i database non possono essere recuperati neanche tramite le repliche o i backup in loco.

Infine è necessario decidere il livello di rischio tollerabile rispetto ai dati archiviati all'interno dei data center del database SQL di Azure. Per informazioni dettagliate sugli strumenti di backup e di ripristino disponibili e su come compilare le strategie di ripristino di emergenza, vedere l'articolo Continuità aziendale del database SQL di Azure in MSDN Library.

Quando si esegue la migrazione effettiva dell'applicazione a Azure, è possibile attenersi agli approcci seguenti:

  • Esecuzione in parallelo: con questo approccio è possibile eseguire l'applicazione in parallelo sia nell'istanza locale sia in Azure. In questo modo è possibile effettuare test reali nell'applicazione in Azure prima che l'applicazione diventi completamente dipendente nel cloud. È consigliabile che nei test sia inclusa la verifica delle funzionalità, delle prestazioni e della scalabilità. Una volta completata l'esecuzione del test del nuovo sistema in Azure, eseguire la migrazione finale dei dati e chiudere il sistema locale.

  • Pausa e trasferimento: questo approccio è appropriato quando è necessario sincronizzare tutti i dati prima della pubblicazione completa in Azure. Se si utilizza questo approccio, i test funzionali e delle prestazioni devono essere innanzitutto completati in Azure. Successivamente, impostare il sistema in modo da consentire la replica dei dati nell'ambiente Azure utilizzando uno dei metodi di sincronizzazione dei dati specificato in precedenza. È consigliabile che i dati vengano mantenuti il più possibile sincronizzati riducendo la quantità di tempo necessario per l'ultima sincronizzazione o l'operazione ETL prima del trasferimento finale. Nel momento in cui è necessario effettuare il trasferimento in Azure, rendere inattivo il sistema locale, eseguire l'ultima sincronizzazione dati e attivare l'applicazione in Azure.

Vedere anche

Mostra:
© 2014 Microsoft