Domande frequenti sull'uso del Servizio Migrazione del database di Azure

Il Servizio Migrazione del database di Azure è un servizio completamente gestito, progettato per abilitare le migrazioni senza interruzioni da più origini di database alle piattaforme di dati di Azure con tempi di inattività minimi. Il servizio è attualmente disponibile a livello generale, con progetti di sviluppo continuativi incentrati su:

• Affidabilità e prestazioni.
• Aggiunta iterativa di coppie origine-destinazione.
• Investimento continuo su migrazioni senza problemi.

Il servizio supporta attualmente varie coppie di origine/destinazione o scenari di migrazione. Per un elenco completo dello stato di ogni scenario di migrazione disponibile vedere l'articolo Stato degli scenari di migrazione supportati dal Servizio Migrazione del database di Azure.

Quando si esegue la migrazione da SQL Server, le origini supportate per il Servizio Migrazione del database di Azure sono SQL Server 2008 e versioni successive.

È possibile usare servizio Migrazione del database di Azure per eseguire migrazioni offline e online. Con una migrazione offline, i tempi di inattività dell'applicazione partono dall'inizio della migrazione. Con una migrazione online, il tempo di inattività è limitato al tempo di cutover alla fine della migrazione. È consigliabile testare una migrazione offline per determinare se il tempo di inattività è accettabile. In caso contrario, eseguire una migrazione online.

Il Servizio Migrazione del database di Azure è il metodo preferito per la migrazione di database in Microsoft Azure su larga scala. Per altre informazioni sulle differenze tra il Servizio Migrazione del database di Azure e altri strumenti di migrazione di database Microsoft e per raccomandazioni sull'uso del servizio in diversi scenari, vedere Differenze tra gli strumenti e i servizi di migrazione di database di Microsoft.

Azure Migrate supporta la migrazione di macchine virtuali locali a IaaS di Azure. Il servizio valuta l'idoneità alla migrazione e il dimensionamento in base alle prestazioni e offre stime dei costi per l'esecuzione delle macchine virtuali locali in Azure. Azure Migrate è utile per le migrazioni in modalità lift-and-shift di carichi di lavoro basati su VM locali a VM IaaS di Azure. Tuttavia, a differenza dell'Azure Database Migration Service, Azure Migrate non è un'offerta di servizio specializzata nella migrazione di database per le piattaforme di database relazionale PaaS di Azure, come Azure SQL Database o Azure SQL Managed Instance.

No. Il Servizio Migrazione del database non archivia i dati dei clienti.

Per SQL Server nella macchina virtuale di Azure e per le destinazioni di istanza gestita di Azure SQL, il servizio di migrazione del database usa la migrazione fisica, ovvero utilizzando il backup e il ripristino. Come descritto nella sezione seguente, la modalità di migrazione scelta determina come i dati vengono mantenuti coerenti tra origine e destinazione.

• Migrazione offline: durante la migrazione offline a SQL Server nella macchina virtuale di Azure e nelle destinazioni di Istanza gestita di SQL di Azure, il tempo di inattività dell'applicazione inizia all'avvio della migrazione. DMS ripristina tutti i file di backup sulla destinazione, a condizione che i file di backup più recenti dall'origine siano stati trasferiti nell'archiviazione di rete SMB o nel contenitore BLOB di Azure, in base alla configurazione della migrazione. Se il backup viene eseguito con l'opzione CHECKSUM, l'operazione di ripristino del DMS esegue automaticamente la convalida. In assenza di checksum, l'integrità del backup viene verificata in modo esplicito prima del ripristino. In questo modo, il file di ripristino è identico al file di backup e pertanto ha gli stessi dati. È possibile verificare tutti i file di backup, incluso il nome dell'ultimo file di backup dall'origine, confrontandoli con il file di backup applicato/ripristinato sulla destinazione mostrato nella pagina di monitoraggio della migrazione del Servizio Migrazione del database e convalidare i rispettivi checksum.

• Migrazione online: durante la migrazione online alla macchina virtuale SQL Server su Azure e alle destinazioni dell'istanza gestita di SQL di Azure, il tempo di inattività inizia al cutover della migrazione insieme all'arresto dell'applicazione. DMS ripristina tutti i file di backup nella destinazione, a condizione che il file o i file di backup più recenti dall'origine siano stati trasferiti all'archiviazione di rete SMB o al contenitore BLOB di Azure, come specificato nella configurazione della migrazione. Dopo aver premuto il pulsante di cutover, il Servizio Migrazione del database mostra il numero di file di backup in sospeso (se presenti) nell'archiviazione di rete SMB o nel contenitore BLOB di Azure che devono ancora essere applicati/ripristinati sulla destinazione. Se il backup viene eseguito con l'opzione CHECKSUM, l'operazione di ripristino del Servizio Migrazione del database (DMS) esegue automaticamente la convalida. In assenza di checksum, l'integrità del backup viene verificata in modo esplicito prima del ripristino. In questo modo, il file di ripristino è identico al file di backup e pertanto ha gli stessi dati. È possibile verificare tutti i file di backup, incluso il nome dell'ultimo file di backup dall'origine, confrontandoli con il file di backup applicato/ripristinato sulla destinazione mostrato nella pagina di monitoraggio della migrazione del Servizio Migrazione del database e convalidare i rispettivi checksum.

Per le destinazioni del database SQL di Azure, Il Servizio Migrazione del database esegue la migrazione logica nel caso del database SQL di Azure. Ovvero copia i dati dalle tabelle del database SQL di origine e li scrive nelle tabelle del database SQL di Azure di destinazione. Poiché Il Servizio Migrazione del database supporta solo la migrazione offline al database SQL di Azure, il tempo di inattività dell'applicazione inizia all'avvio della migrazione. È possibile monitorare e convalidare il numero di righe lette (dalla tabella del database di origine) e copiate (scritte nella tabella di database SQL di Azure di destinazione) dalla pagina di monitoraggio della migrazione. Come conferma aggiuntiva, è possibile eseguire il Transact-SQL seguente per ottenere il checksum sia nei database di origine che in quello di destinazione e convalidare che i dati di origine e ripristino siano identici.

SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;

L'elenco seguente contiene le risorse di Azure che possono essere create in background per eseguire una migrazione dei dati. I servizi usati possono variare in base allo scenario di migrazione.

• Monitoraggio di Azure
• Macchina virtuale di Azure
• Archiviazione di Azure
• Bus di servizio di Azure
• Azure Data Factory

Internamente, DMS mantiene un archivio di metadati che include informazioni sui percorsi di rete, le credenziali, i file di backup e le attività completate. Le credenziali e i campi selezionati, ad esempio le chiavi dell'account, vengono crittografati. I dati, come i nomi di tabella che potrebbero essere inclusi nella telemetria, vengono hashati. I nomi utente potrebbero essere visualizzati in testo normale nei log del servizio, ma le password non verranno mai visualizzate. I dati di telemetria sono isolati per area, regolati da politiche di conservazione e disponibili solo per il personale autorizzato all'interno di Microsoft per scopi legittimi di risoluzione dei problemi. I nomi delle risorse di Azure, ad esempio i nomi di server e database, seguono le regole per le risorse di Azure.

DMS (versione classica) utilizza gli argomenti di Azure Service Bus per facilitare la comunicazione tra i livelli di calcolo. Gli argomenti del bus di servizio di Azure sono univoci per ogni istanza DMS e tutti i dati personali vengono crittografati.

Istanza gestita di SQL di Azure e SQL Server in macchine virtuali di Azure

La migrazione dello schema e dei dati viene eseguita usando il backup e il ripristino. I clienti hanno la possibilità di eseguire il ripristino da una condivisione di rete o direttamente da un contenitore di archiviazione. Un file contenente i dati sulle prestazioni di Windows potrebbe essere utilizzato per fornire raccomandazioni di dimensionamento facoltative (ma altamente consigliate) del carico di lavoro.

Database SQL di Azure

Le migrazioni al database SQL di Azure vengono eseguite in due passaggi. Il primo passaggio è una migrazione dello schema. DMS (classico) usa SQL Management Objects (SMO) per la migrazione dello schema. Il secondo passaggio è la migrazione effettiva dei dati. SqlBulkCopy viene usato per eseguire la migrazione dei dati. Il DMS non supporta la migrazione dello schema. I dati vengono migrati usando Azure Data Factory. Facoltativamente, ma altamente consigliato, potrebbe essere utilizzato un file contenente i dati sulle prestazioni di Windows per fornire raccomandazioni sul ridimensionamento del carico di lavoro.

Database di Azure per PostgreSQL

In questo scenario, l'utente finale estrae i metadati, in questo caso lo schema, usando le utilità della riga di comando pg_dump e pg_restore. Quando si configura Change Data Capture per PostgreSQL, DMS usa internamente pg_dump e pg_restore per eseguire l'inizializzazione iniziale per CDC. I dati vengono archiviati in un archivio temporaneo crittografato accessibile solo alla tua istanza del DMS. Un file contenente i dati sulle prestazioni di Windows potrebbe essere utilizzato per fornire raccomandazioni di dimensionamento facoltative (ma altamente consigliate) del carico di lavoro.

Database di Azure per MySQL

In questo scenario, l'estrazione e la migrazione dello schema vengono eseguite dal Servizio Migrazione del database (versione classica) usando mysql-net/MySqlConnector. Laddove possibile, la replica binlog di MySQL viene usata per replicare sia i dati che le modifiche dello schema. Il codice personalizzato viene usato per sincronizzare le modifiche in cui non è possibile usare la replica binlog.

Da MongoDB ad Azure Cosmos DB

Il DMS estrae e inserisce dati da un MongoDB in Cosmos DB. Offre anche la possibilità di estrarre i dati da un dump BSON o JSON.

Per i dump BSON, DMS utilizza i dati nel formato bsondump nella stessa cartella all'interno di un contenitore BLOB. DMS cerca solo i file di metadati usando il formato collection.metadata.json.

Per i dump JSON, il Servizio Migrazione del database leggerà i file nelle cartelle del contenitore BLOB denominate con i nomi dei database a cui appartengono. All'interno di ogni cartella del database, DMS usa solo i file di dati inseriti nella sottocartella data. DMS esamina solo i file inseriti nella sottocartella metadata e nominati con il formato collection.json per i metadati.

Migrazione da Oracle a Database di Azure per PostgreSQL

Analogamente a Oracle al database SQL di Azure, in questo scenario, il report AWR o un file di Windows perfmon viene usato per fornire raccomandazioni di dimensionamento facoltative (ma altamente consigliate). La libreria ora2pg viene usata per estrarre lo schema ed eseguire manualmente la migrazione dei dati dall'utente che esegue la migrazione.

DMS (versione classica) si basa sulla configurazione della rete del cliente. Se l'origine della migrazione usa endpoint privati, si usano endpoint privati, ovvero la configurazione preferita. Gli endpoint pubblici vengono usati se sono l'unica opzione.

Il Database Migration Service utilizza ADF intensivamente dietro le quinte, per la pianificazione e il coordinamento dello spostamento dei dati. Inoltre, il Self-Hosted Integration Runtime non è diverso da quello che probabilmente già usi per le pipeline di Azure Data Factory. Per altre informazioni sui problemi del firewall e del server proxy, vedere Creare e configurare un runtime di integrazione self-hosted.

Tutti i dati dei clienti sono crittografati quando sono a riposo. Alcuni metadati, inclusi i nomi dei server logici e i nomi dei database, nonché lo stato di migrazione e l'avanzamento della migrazione, appaiono nei log del servizio in forma non crittografata.

Tutti i dati in transito sono protetti con la crittografia TLS 1.2 per impostazione predefinita. I client legacy che necessitano di versioni precedenti di TLS devono avere tali versioni abilitate nella pagina del portale del Servizio di Migrazione del Database (versione classica). Per il Servizio Migrazione del database, è possibile configurare il computer in cui è installato Integration Runtime self-hosted in modo che le impostazioni TLS richieste supportino i client legacy. Per altre informazioni sulla configurazione tls per SQL Server, vedere Supporto di TLS 1.2 per Microsoft SQL Server.

Laddove possibile, vengono usati endpoint privati. Se gli endpoint privati non sono un'opzione, gli endpoint pubblici vengono usati per la comunicazione tra livelli di servizio. Indipendentemente dal tipo di endpoint, tutte le risorse sono dedicate all'istanza particolare del Servizio Migrazione del database e protette con credenziali univoche.

Le chiavi gestite dal cliente non sono supportate per la crittografia dei dati all'interno del piano dati o del piano di controllo. Tuttavia, tutti i dati dei clienti sono crittografati a riposo utilizzando chiavi gestite dal servizio. Alcuni metadati, inclusi i nomi dei server logici e i nomi dei database, nonché lo stato di migrazione e lo stato di avanzamento vengono visualizzati nei log del servizio in formato non crittografato.

Per impostazione predefinita, tutti i dati in transito vengono crittografati con la crittografia TLS 1.2. La pagina del portale DMS (classico) consente l'uso di versioni precedenti di TLS per i client legacy. Per il Servizio Migrazione del database, è possibile configurare il computer in cui è installato Integration Runtime self-hosted per gestire le impostazioni TLS in modo che supportino i client legacy. Per altre informazioni sulla configurazione tls per SQL Server, vedere Supporto di TLS 1.2 per Microsoft SQL Server.

Non è possibile esporre la funzionalità per crittografare i dati nel piano dati o nel controllo con le chiavi gestite dal cliente. Tutti i dati cliente vengono eliminati nel momento in cui l'istanza del Servizio Migrazione del database viene eliminata, ad eccezione dei log del servizio. I log del servizio di migrazione del database vengono conservati solo per 6 mesi.

TDE

DMS supporta la migrazione delle Customer Managed Keys (CMK) ad Azure SQL per la Transparent Database Encryption (TDE).

Crittografia delle celle

La crittografia a livello di cella viene gestita a livello di schema. Gli strumenti di migrazione dello schema consentono di eseguire la migrazione di tutti gli oggetti schema, incluse le funzioni e le stored procedure necessarie per implementare la crittografia a livello di cella.

Sempre Crittografato

Il Servizio Migrazione del database non supporta attualmente la migrazione di Always Encrypted tramite scenari in cui viene eseguita la migrazione di singole righe di dati tra origine e destinazione. Le colonne crittografate tramite Always Encrypted vengono migrate come previsto in scenari che usano backup/ripristino, ad esempio il passaggio a SQL Server in una macchina virtuale di Azure o un'istanza gestita di SQL di Azure, da un'istanza di SQL Server esistente.

Non vengono implementati controlli di accesso in grado di conoscere la posizione oltre a ciò che è già disponibile in Azure. Tutti i dati associati a un'istanza DMS risiedono nella stessa regione della risorsa DMS.

I nostri servizi vengono usati in vari ambienti con diversi controlli interni e processi aziendali. Il DMS sposta i dati da e verso qualsiasi posizione a cui l'account in uso abbia accesso. È responsabilità dell'utente comprendere le autorizzazioni e i controlli interni dell'ambiente in cui lavora. È particolarmente importante assicurarsi che l'account usato dal Servizio Migrazione del database per connettersi all'origine abbia accesso per visualizzare tutti i dati di cui si intende eseguire la migrazione dall'origine.

Iniezione di rete virtuale è l'operazione di aggiunta di una risorsa di Azure che risiede nel tenant Microsoft a una subnet in una rete virtuale nel tenant del cliente. Questo approccio è stato adottato con DMS per consentire di gestire la computazione per conto del cliente, pur mantenendo l'accesso alle risorse dei clienti. Poiché la rete si trova nella sottoscrizione del cliente, Microsoft non può gestire la macchina virtuale oltre all'emissione di comandi Start, Stop, Delete o Deploy. Tutte le altre azioni di gestione che richiedono l'accesso alla macchina virtuale richiedono una richiesta di supporto e un'approvazione avviate dal cliente.

Esistono diversi prerequisiti obbligatori per assicurare che il Servizio Migrazione del database di Azure venga eseguito senza problemi quando si eseguono migrazioni di database. Alcuni dei prerequisiti si applicano a tutti gli scenari (coppie di origine-destinazione) supportati dal servizio, mentre altri prerequisiti sono univoci per uno scenario specifico.

In base ai prerequisiti del Servizio Migrazione del database di Azure comuni a tutti gli scenari di migrazione supportati, è necessario:

• Creare una rete virtuale di Microsoft Azure per il servizio Migrazione del database di Azure usando il modello di distribuzione Azure Resource Manager, che offre la connettività da sito a sito per i server di origine locali con ExpressRoute o VPN.
• Assicurarsi che le regole del gruppo di sicurezza di rete della rete virtuale non blocchino la porta 443 per i tag del servizio per il bus del servizio, l'archiviazione e il monitoraggio di Azure. Per informazioni dettagliate sul filtro del traffico dei gruppi di sicurezza di rete della rete virtuale di Azure, vedere l'articolo Filtrare il traffico di rete con gruppi di sicurezza di rete.
• Quando si usa un'appliance firewall davanti ai database di origine, potrebbe essere necessario aggiungere regole del firewall per consentire Servizio Migrazione del database di Azure di accedere ai database di origine per la migrazione.

Per un elenco di tutti i prerequisiti obbligatori per supportare scenari di migrazione specifici con il Servizio Migrazione del database di Azure, vedere le esercitazioni correlate nella documentazione del Servizio Migrazione del database di Azure.

Potrebbe essere necessario aggiungere regole del firewall che consentono al Servizio Migrazione del database di Azure di accedere al database di origine per la migrazione. L'indirizzo IP per il servizio è dinamico, ma, se si usa Express Route, questo indirizzo viene assegnato privatamente dalla rete aziendale. Il modo più semplice per identificare l'indirizzo IP appropriato è cercare nello stesso gruppo di risorse della risorsa del Servizio Migrazione del database di Azure di cui viene effettuato il provisioning per trovare l'interfaccia di rete associata. In genere il nome della risorsa interfaccia di rete inizia con il prefisso NIC e seguito da una sequenza di caratteri e numeri univoci, NIC-jj6tnztnmarpsskr82rbndypad esempio . Quando selezioni questa risorsa dell'interfaccia di rete, puoi visualizzare l'indirizzo IP che deve essere incluso nella lista di autorizzazioni sulla pagina di panoramica del portale Azure.

Potrebbe anche essere necessario includere la porta su cui SQL Server è in ascolto nella lista autorizzata. Per impostazione predefinita, è la porta 1433, ma SQL Server di origine può essere configurato anche per l'ascolto su altre porte. In questo caso, è necessario includere anche tali porte nell'elenco indirizzi consentiti. È possibile determinare la porta su cui SQL Server è in ascolto usando una query Dynamic Management View.

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

È anche possibile determinare la porta su cui SQL Server è in ascolto eseguendo una query sul log degli errori di SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Oltre alle numerose guide Microsoft che possono guidarti nel processo di configurazione di una rete virtuale, la documentazione ufficiale è disponibile nell'articolo Rete virtuale di Azure.

Durante una semplice migrazione di database tipica, è necessario:

1. Creare database di destinazione.
2. Valutare i database di origine con SSMA. SSMA può anche convertire gli oggetti di database ed eseguire la migrazione dello schema alla piattaforma di destinazione.
3. Creare un'istanza del servizio Migrazione del database di Azure.
4. Creare un progetto di migrazione che specifica i database di origine, i database di destinazione e le tabelle di cui eseguire la migrazione.
5. Avvia il caricamento completo.
6. Selezionare la convalida successiva.
7. Eseguire un passaggio manuale dell'ambiente di produzione al nuovo database basato sul cloud.

Se si verificano problemi di connessione al sistema di database di origine durante la migrazione, crea una macchina virtuale nella stessa subnet della rete virtuale con cui hai configurato la tua istanza DMS. Nella macchina virtuale dovrebbe essere possibile eseguire un test di connessione, ad esempio usando un file UDL per testare una connessione a SQL Server o scaricare Robo 3T per testare le connessioni MongoDB. Se il test di connessione ha esito positivo, non dovrebbe verificarsi alcun problema con la connessione al database di origine. Se il test di connessione ha esito negativo, contattare l'amministratore di rete.

Se l'utente arresta esplicitamente il Servizio Migrazione del database di Azure (DMS) o se il servizio rimane inattivo per 24 ore, viene attivato uno stato di arresto o sospensione automatica. In ogni caso, il servizio non è disponibile ed è fermo. Per riprendere l'esecuzione delle migrazioni attive, riavviare il servizio.

È possibile eseguire alcune operazioni per velocizzare la migrazione del database con il servizio:

Per DMS (classico):

• Usare il piano tariffario per utilizzo generico per più CPU quando si crea l'istanza del servizio per consentire al servizio di sfruttare più vCPU per la parallelizzazione e un trasferimento dei dati più veloce.
• Aumentare temporaneamente l'istanza di destinazione del database SQL di Azure al livello Premium dello SKU durante l'operazione di migrazione dei dati per ridurre al minimo il throttling del database SQL di Azure, che può influire sulle attività di trasferimento dei dati quando si utilizzano SKU di livello inferiore.

Per DMS:

• Se si copiano backup dalla condivisione file locale all'archiviazione BLOB di Azure o durante la migrazione a un database SQL di Azure di destinazione, il servizio Migrazione del database utilizza il nodo SHIR come risorsa di calcolo. Assicurarsi quindi di monitorare l'utilizzo delle risorse del nodo SHIR.
• Aumentare temporaneamente l'istanza di destinazione del database SQL di Azure allo SKU di livello Premium durante l'operazione di migrazione dei dati per ridurre al minimo la limitazione del disco del database SQL di Azure che può influire sulle attività di trasferimento dei dati quando si usano SKU di livello inferiore.
• Per informazioni più dettagliate, vedere Miglioramento delle prestazioni della migrazione del database SQL - Servizio Migrazione del database di Azure.

Contenuti correlati

• Definizione del Servizio Migrazione del database di Azure.