Eseguire la migrazione delle risorse del database ad Azure globale

  • Articolo

Importante

Dal mese di agosto 2018 non sono stati accettati nuovi clienti o sono stati distribuiti nuovi servizi e funzionalità nelle posizioni originali di Microsoft Cloud Germania.

In base all'evoluzione delle esigenze dei clienti, recentemente abbiamo lanciato due nuove aree del data center in Germania, offrendo la residenza dei dati dei clienti, la connettività completa alla rete cloud globale di Microsoft, nonché prezzi competitivi sul mercato.

Inoltre, il 30 settembre 2020, abbiamo annunciato che Microsoft Cloud Germania chiuderà il 29 ottobre 2021. Altri dettagli sono disponibili qui: https://www.microsoft.com/cloud-platform/germany-cloud-regions.

Sfruttare l'ampia gamma di funzionalità, sicurezza di livello aziendale e funzionalità complete disponibili nelle nuove aree data center tedesche eseguendo la migrazione oggi.

Questo articolo contiene informazioni che consentono di eseguire la migrazione delle risorse del database di Azure da Azure Germania a Azure globale.

Database SQL

Per eseguire la migrazione di carichi di lavoro di database più piccoli Azure SQL, senza mantenere online il database migrato, usare la funzione di esportazione per creare un file BACPAC. Un file BACPAC è un file compresso (compresso) che contiene metadati e i dati dal database SQL Server. Dopo aver creato il file BACPAC, è possibile copiare il file nell'ambiente di destinazione, ad esempio usando AzCopy, e usare la funzione di importazione per ricompilare il database. Tenere presente le considerazioni seguenti:

  • Affinché un'esportazione sia coerente in modo transazionale, assicurarsi che una delle condizioni seguenti sia true:
    • Nessuna attività di scrittura si verifica durante l'esportazione.
    • Si esporta da una copia coerente con transazioni del database SQL.
  • Per esportare nell'archiviazione BLOB di Azure, le dimensioni del file BACPAC sono limitate a 200 GB. Per un file BACPAC più grande, esportare nell'archiviazione locale.
  • Se l'operazione di esportazione da database SQL richiede più di 20 ore, l'operazione potrebbe essere annullata. Per suggerimenti su come aumentare le prestazioni, vedere gli articoli seguenti.

Nota

Il stringa di connessione cambia dopo l'operazione di esportazione perché il nome DNS del server cambia durante l'esportazione.

Per altre informazioni:

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Eseguire la migrazione di database SQL usando la replica geografica attiva

Per i database troppo grandi per i file BACPAC o per eseguire la migrazione da un cloud a un altro e rimanere online con tempi di inattività minimi, è possibile configurare la replica geografica attiva da Azure Germania a Azure globale.

Importante

La configurazione della replica geografica attiva per la migrazione dei database in Azure globale è supportata solo tramite Transact-SQL (T-SQL) e prima della migrazione è necessario richiedere l'abilitazione della sottoscrizione per supportare la migrazione ad Azure globale. Per inviare una richiesta, è necessario usare questo collegamento alla richiesta di supporto.

Nota

Le aree cloud globali di Azure, Germania occidentale e Germania settentrionale, sono le aree supportate per la replica geografica attiva con il cloud Azure Germania. Se un'area di Azure globale alternativa è desiderata come destinazione dei database finali, la raccomandazione dopo il completamento della migrazione ad Azure globale consiste nel configurare un collegamento di replica geografica aggiuntivo da Germania occidentale o Germania settentrionale all'area cloud globale di Azure necessaria.

Per informazioni dettagliate sui costi di replica geografica attiva, vedere la sezione intitolata Replica geografica attiva in Azure SQL Prezzi del database.

La migrazione di database con replica geografica attiva richiede un server logico Azure SQL in Azure globale. È possibile creare il server usando il portale, Azure PowerShell, l'interfaccia della riga di comando di Azure e così via, ma la configurazione della replica geografica attiva per la migrazione da Azure Germania a Azure globale è supportata solo tramite Transact-SQL (T-SQL).

Importante

Quando si esegue la migrazione tra cloud, i prefissi del nome del server primario (Azure Germania) e secondario (Azure globale) devono essere diversi. Se i nomi dei server sono uguali, l'esecuzione dell'istruzione ALTER DATABASE avrà esito positivo, ma la migrazione avrà esito negativo. Ad esempio, se il prefisso del nome del server primario è myserver (myserver.database.cloudapi.de), il prefisso del nome del server secondario in Azure globale non può essere myserver.

L'istruzione ALTER DATABASE consente di specificare un server di destinazione in Azure globale usando il nome completo del server DNS sul lato di destinazione.

ALTER DATABASE [sourcedb] add secondary on server [public-server.database.windows.net]
  • sourcedbrappresenta il nome del database in un server Azure SQL in Azure Germania.
  • public-server.database.windows.netrappresenta il nome del server Azure SQL esistente in Azure globale, in cui il database deve essere migrato. Lo spazio dei nomi "database.windows.net" è necessario, sostituire public-server con il nome del server SQL logico in Azure globale. Il server in Azure globale deve avere un nome diverso dal server primario in Azure Germania.

Il comando viene eseguito nel database master nel server di Azure Germania che ospita il database locale da eseguire per la migrazione.

  • L'API di avvio-copia T-SQL autentica l'utente connesso nel server cloud pubblico trovando un utente con lo stesso nome utente/account di accesso SQL nel database master di tale server. Questo approccio è cloud-agnostico; pertanto, l'API T-SQL viene usata per avviare copie cross-cloud. Per le autorizzazioni e altre informazioni su questo argomento, vedere Creazione e uso della replica geografica attiva e ALTER DATABASE (Transact-SQL).

  • Ad eccezione dell'estensione del comando T-SQL iniziale che indica un server logico Azure SQL in Azure globale, il resto del processo di replica geografica attiva è identico all'esecuzione esistente nel cloud locale. Per i passaggi dettagliati per creare la replica geografica attiva, vedere Creazione e uso della replica geografica attiva con un'eccezione che il database secondario viene creato nel server logico secondario creato in Azure globale.

  • Dopo aver esistente il database secondario in Azure globale (come copia online del database di Azure Germania), il cliente può avviare un failover del database da Azure Germania a azure globale per questo database usando il comando ALTER DATABASE T-SQL (vedere la tabella seguente).

  • Dopo il failover, una volta che il database secondario diventa un database primario in Azure globale, è possibile arrestare la replica geografica attiva e rimuovere il database secondario sul lato Azure Germania in qualsiasi momento (vedere la tabella seguente e i passaggi presenti nel diagramma).

  • Dopo il failover, il database secondario in Azure Germania continuerà a comportare costi fino all'eliminazione.

  • L'uso del comando è l'unico ALTER DATABASE modo per configurare la replica geografica attiva per eseguire la migrazione di un database di Azure Germania ad Azure globale.

  • Non è disponibile portale di Azure, Azure Resource Manager, PowerShell o interfaccia della riga di comando per configurare la replica geografica attiva per questa migrazione.

Per eseguire la migrazione di un database da Azure Germania ad Azure globale:

  1. Scegliere il database utente in Azure Germania, ad esempio azuregermanydb

  2. Creare un server logico in Azure globale (cloud pubblico), ad esempio globalazureserver. Il nome di dominio completo (FQDN) è globalazureserver.database.windows.net.

  3. Avviare la replica geografica attiva da Azure Germania a Azure globale eseguendo questo comando T-SQL nel server in Azure Germania. Si noti che il nome DNS completo viene usato per il server globalazureserver.database.windows.netpubblico. Si tratta di indicare che il server di destinazione si trova in Azure globale e non in Azure Germania.

    ALTER DATABASE [azuregermanydb] ADD SECONDARY ON SERVER [globalazureserver.database.windows.net];

  4. Quando la replica è pronta per spostare il carico di lavoro di lettura-scrittura nel server di Azure globale, avviare un failover pianificato in Azure globale eseguendo questo comando T-SQL nel server di Azure globale.

    ALTER DATABASE [azuregermanydb] FAILOVER;

  5. Il collegamento di replica geografica attiva può essere terminato prima o dopo il processo di failover. L'esecuzione del comando T-SQL seguente dopo la failover pianificato rimuove il collegamento alla replica geografica con il database in Azure globale che rappresenta la copia di lettura-scrittura. Deve essere eseguito nel server logico del database geo-primario corrente, ad esempio nel server globale di Azure. Verrà completato il processo di migrazione.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [azuregermanyserver];

    Il comando T-SQL seguente quando viene eseguito prima dell'failover pianificato arresta anche il processo di migrazione, ma in questa situazione il database in Azure Germania rimarrà la copia di lettura-scrittura. Questo comando T-SQL deve essere eseguito anche nel server logico del database geo-primario corrente, in questo caso nel server di Azure Germania.

    ALTER DATABASE [azuregermanydb] REMOVE SECONDARY ON SERVER [globalazureserver];

Questi passaggi per eseguire la migrazione di database Azure SQL da Azure Germania a Azure globale possono essere seguiti anche usando la replica geografica attiva.

Per altre informazioni, le tabelle seguenti indicano comandi T-SQL per la gestione del failover. I comandi seguenti sono supportati per la replica geografica attiva cross-cloud tra Azure Germania e Azure globale:

Comando Descrizione
ALTER DATABASE Usare l'argomento ADD SECONDARY ON SERVER per creare un database secondario per un database esistente e avviare la replica dei dati
ALTER DATABASE Usare FAILOVER o FORCE_FAILOVER_ALLOW_DATA_LOSS per passare un database secondario al ruolo di database primario per avviare il failover
ALTER DATABASE Usare REMOVE SECONDARY ON SERVER per terminare la replica dei dati tra un database SQL e il database secondario specificato.

Visualizzazioni del sistema di monitoraggio della replica geografica attiva

Comando Descrizione
sys.geo_replication_links Restituisce informazioni su tutti i collegamenti di replica esistenti per ogni database nel server di database SQL di Azure.
sys.dm_geo_replication_link_status Ottiene l'ultima ora di replica, l'ultimo intervallo di replica e altre informazioni sul collegamento di replica per un database SQL specificato.
sys.dm_operation_status Mostra lo stato per tutte le operazioni di database, incluso lo stato dei collegamenti di replica.
sp_wait_for_database_copy_sync Causa l'attesa dell'applicazione fino a quando tutte le transazioni di commit vengono replicate e riconosciute dal database secondario attivo.

Eseguire la migrazione database SQL backup di conservazione a lungo termine

La migrazione di un database con replica geografica o file BACPAC non copia nei backup di conservazione a lungo termine, che il database potrebbe avere in Azure Germania. Per eseguire la migrazione dei backup di conservazione a lungo termine esistenti all'area globale di Azure di destinazione, è possibile usare la procedura di backup di conservazione a lungo termine COPY.

Nota

I metodi di copia di backup LTR documentati qui possono copiare solo i backup LTR da Azure Germania a Azure globale. La copia dei backup PITR con questi metodi non è supportata.

Prerequisiti

  1. Il database di destinazione in cui si copiano i backup LTR, in Azure globale deve esistere prima di avviare la copia dei backup. È consigliabile eseguire prima la migrazione del database di origine usando la replica geografica attiva e quindi avviare la copia di backup LTR. Ciò garantisce che i backup del database vengano copiati nel database di destinazione corretto. Questo passaggio non è obbligatorio, se si esegue la copia su backup LTR di un database eliminato. Quando si copiano i backup LTR di un database eliminato, verrà creato un ID database fittizio nell'area di destinazione.
  2. Installare questo modulo Az di PowerShell
  3. Prima di iniziare, assicurarsi che i ruoli di controllo degli accessi in base al ruolo di Azure necessari vengano concessi all'ambito della sottoscrizione o del gruppo di risorse . Nota: per accedere ai backup LTR appartenenti a un server eliminato, è necessario concedere l'autorizzazione nell'ambito della sottoscrizione di tale server. .

Limitazioni

  • I gruppi di failover non sono supportati. Ciò significa che i clienti che eseguono la migrazione dei database di Azure Germania dovranno gestire le stringhe di connessione stesse durante il failover.
  • Nessun supporto per portale di Azure, API di Azure Resource Manager, PowerShell o interfaccia della riga di comando. Ciò significa che ogni migrazione di Azure Germania dovrà gestire la configurazione e il failover della replica geografica attiva tramite T-SQL.
  • I clienti non possono creare più secondarie geografiche in Azure globale per i database in Azure Germania.
  • La creazione di un secondario geografico deve essere avviata dall'area di Azure Germania.
  • I clienti possono eseguire la migrazione dei database da Azure Germania solo ad Azure globale. Attualmente non è supportata alcuna altra migrazione cross-cloud.
  • Gli utenti di Azure AD nei database utente di Azure Germania vengono migrati ma non sono disponibili nel nuovo tenant di Azure AD in cui risiede il database migrato. Per abilitare questi utenti, devono essere eliminati manualmente e ricreati usando gli utenti di Azure AD correnti disponibili nel nuovo tenant di Azure AD in cui risiede il database appena migrato.

Copiare backup di conservazione a lungo termine con PowerShell

È stato introdotto un nuovo comando di PowerShell Copy-AzSqlDatabaseLongTermRetentionBackup , che può essere usato per copiare i backup di conservazione a lungo termine da Azure Germania alle aree globali di Azure.

  1. Copiare il backup LTR usando il nome di backup Nell'esempio seguente viene illustrato come copiare un backup LTR da Azure Germania all'area globale di Azure usando il nome backup.
# Source database and target database info
$location = "<location>"
$sourceRGName = "<source resourcegroup name>"
$sourceServerName = "<source server name>"
$sourceDatabaseName = "<source database name>"
$backupName = "<backup name>"
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -Location $location 
    -ResourceGroupName $sourceRGName 
    -ServerName $sourceServerName 
    -DatabaseName $sourceDatabaseName
    -BackupName $backupName
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN
  1. Copiare il backup LTR usando resourceID di backup Nell'esempio seguente viene illustrato come copiare il backup LTR da Azure Germania all'area globale di Azure usando un resourceID di backup. Questo esempio può essere usato anche per copiare i backup di un database eliminato.
$location = "<location>"
# list LTR backups for All databases (you have option to choose All/Live/Deleted)
$ltrBackups = Get-AzSqlDatabaseLongTermRetentionBackup -Location $location -DatabaseState All

# select the LTR backup you want to copy
$ltrBackup = $ltrBackups[0]
$resourceID = $ltrBackup.ResourceId

# Source Database and target database info
$targetDatabaseName = "<target database name>"
$targetSubscriptionId = "<target subscriptionID>"
$targetRGName = "<target resource group name>"
$targetServerFQDN = "<targetservername.database.windows.net>"

Copy-AzSqlDatabaseLongTermRetentionBackup 
    -ResourceId $resourceID 
    -TargetDatabaseName $targetDatabaseName 
    -TargetSubscriptionId $targetSubscriptionId
    -TargetResourceGroupName $targetRGName
    -TargetServerFullyQualifiedDomainName $targetServerFQDN

Limitazioni

  • I backup PITR (Point-In-Time Restore) vengono eseguiti solo nel database primario, ovvero in base alla progettazione. Quando si esegue la migrazione di database da Azure Germania con Geo-DR, i backup PITR inizieranno a verificarsi nel nuovo database primario dopo il failover. Tuttavia, i backup PITR esistenti (nel precedente primario in Azure Germania) non verranno migrati. Se sono necessari backup PITR per supportare gli scenari di ripristino temporizzato, è necessario ripristinare il database dai backup PITR in Azure Germania e quindi eseguire la migrazione del database ripristinato in Azure globale.
  • I criteri di conservazione a lungo termine non vengono migrati con il database. Se si dispone di criteri di conservazione a lungo termine (LTR) nel database in Azure Germania, è necessario copiare e ricreare manualmente i criteri LTR nel nuovo database dopo la migrazione.

Richiesta di accesso

Per eseguire la migrazione di un database da Azure Germania a Azure globale usando la replica geografica, è necessario abilitare la sottoscrizione in Azure Germania per configurare correttamente la migrazione tra cloud.

Per abilitare la sottoscrizione di Azure Germania, è necessario usare il collegamento seguente per creare una richiesta di supporto per la migrazione:

  1. Passare alla richiesta di supporto della migrazione seguente.

  2. Nella scheda Nozioni di base immettere Migrazione di Ripristino di emergenza geografico come riepilogo e quindi selezionare Avanti: Soluzioni

    nuovo modulo di richiesta di supporto

  3. Esaminare i passaggi consigliati, quindi selezionare Avanti: Dettagli.

    informazioni sulla richiesta di supporto richieste di supporto necessarie

  4. Nella pagina dei dettagli specificare quanto segue:

    1. Nella casella Descrizione immettere l'ID sottoscrizione di Azure globale da eseguire per la migrazione. Per eseguire la migrazione dei database a più sottoscrizioni, aggiungere un elenco degli ID di Azure globali a cui si vuole eseguire la migrazione dei database.
    2. Specificare le informazioni di contatto: nome, nome dell'azienda, posta elettronica o numero di telefono.
    3. Completare il modulo e quindi selezionare Avanti: Rivedi e crea.

    dettagli della richiesta di supporto

  5. Esaminare la richiesta di supporto e quindi selezionare Crea.

Dopo l'elaborazione della richiesta, verrà contattato.

Azure Cosmos DB

È possibile usare Lo strumento di migrazione dei dati di Azure Cosmos DB per eseguire la migrazione dei dati ad Azure Cosmos DB. Azure Cosmos DB Data Migration Tool è una soluzione open source che importa dati in Azure Cosmos DB da origini diverse, tra cui file JSON, MongoDB, SQL Server, file CSV, archiviazione tabelle di Azure, Amazon DynamoDB, HBase e contenitori Azure Cosmos.

Azure Cosmos DB Data Migration Tool è disponibile come strumento di interfaccia grafica o come strumento da riga di comando. Il codice sorgente è disponibile nel repository GitHub dello strumento di migrazione dei dati di Azure Cosmos DB . Una versione compilata dello strumento è disponibile nell'Area download Microsoft.

Per eseguire la migrazione delle risorse di Azure Cosmos DB, è consigliabile completare la procedura seguente:

  1. Esaminare i requisiti di tempo di attività dell'applicazione e le configurazioni dell'account per determinare il piano di azione migliore.
  2. Clonare le configurazioni dell'account da Azure Germania alla nuova area eseguendo lo strumento di migrazione dei dati.
  3. Se si usa una finestra di manutenzione, copiare i dati dall'origine alla destinazione eseguendo lo strumento di migrazione dei dati.
  4. Se si usa una finestra di manutenzione non è un'opzione, copiare i dati dall'origine alla destinazione eseguendo lo strumento e quindi completare questi passaggi:
    1. Usare un approccio basato su configurazione per apportare modifiche alla lettura/scrittura in un'applicazione.
    2. Completare una sincronizzazione per la prima volta.
    3. Configurare una sincronizzazione incrementale e recuperare il feed di modifiche.
    4. Punta al nuovo account e convalida l'applicazione.
    5. Arrestare le scritture nell'account precedente, verificare che il feed di modifiche venga rilevato e quindi puntare le scritture nel nuovo account.
    6. Arrestare lo strumento ed eliminare l'account precedente.
  5. Eseguire lo strumento per verificare che i dati siano coerenti tra gli account precedenti e nuovi.

Per altre informazioni:

Cache di Azure per Redis

Sono disponibili alcune opzioni per eseguire la migrazione di un'istanza di cache di Azure per Redis da Azure Germania ad Azure globale. L'opzione scelta dipende dai requisiti.

Opzione 1: Accettare la perdita di dati, creare una nuova istanza

Questo approccio ha il maggior senso quando entrambe le condizioni seguenti sono vere:

  • Si usa cache di Azure per Redis come cache dei dati temporanei.
  • L'applicazione ripopola automaticamente i dati della cache nella nuova area.

Per eseguire la migrazione con perdita di dati e creare una nuova istanza:

  1. Creare una nuova istanza cache di Azure per Redis nella nuova area di destinazione.
  2. Aggiornare l'applicazione per usare la nuova istanza nella nuova area.
  3. Eliminare l'istanza di cache di Azure per Redis precedente nell'area di origine.

Opzione 2: Copiare i dati dall'istanza di origine all'istanza di destinazione

Un membro del team di cache di Azure per Redis ha scritto uno strumento open source che copia i dati da un'istanza cache di Azure per Redis a un'altra senza richiedere funzionalità di importazione o esportazione. Per informazioni sullo strumento, vedere il passaggio 4 nei passaggi seguenti.

Per copiare i dati dall'istanza di origine all'istanza di destinazione:

  1. Creare una macchina virtuale nell'area di origine. Se il set di dati in cache di Azure per Redis è di grandi dimensioni, assicurarsi di selezionare una dimensione di macchina virtuale relativamente potente per ridurre al minimo il tempo di copia.
  2. Creare una nuova istanza di cache di Azure per Redis nell'area di destinazione.
  3. Scaricare i dati dall'istanza di destinazione . Assicurarsi di non scaricare dall'istanza di origine . È necessario scaricare perché lo strumento di copia non sovrascrive le chiavi esistenti nel percorso di destinazione.
  4. Usare lo strumento seguente per copiare automaticamente i dati dall'istanza di origine cache di Azure per Redis all'istanza di destinazione cache di Azure per Redis: originestrumento e download degli strumenti.

Nota

Questo processo può richiedere molto tempo a seconda delle dimensioni del set di dati.

Opzione 3: Esportare dall'istanza di origine, importare nell'istanza di destinazione

Questo approccio sfrutta le funzionalità disponibili solo nel livello Premium.

Per esportare dall'istanza di origine e importare nell'istanza di destinazione:

  1. Creare un nuovo livello Premium cache di Azure per Redis'istanza nell'area di destinazione. Usare le stesse dimensioni dell'istanza di cache di Azure per Redis di origine.

  2. Esportare dati dalla cache di origine o usare il cmdlet di PowerShell Export-AzRedisCache.

    Nota

    L'account di archiviazione di Azure di esportazione deve trovarsi nella stessa area dell'istanza della cache.

  3. Copiare i BLOB esportati in un account di archiviazione nell'area di destinazione, ad esempio usando AzCopy.

  4. Importare dati nella cache di destinazione o usare il cmdlet di PowerShell Import-AzRedisCAche.

  5. Riconfigurare l'applicazione in modo da usare l'istanza di cache di Azure per Redis di destinazione.

Opzione 4: Scrivere dati in due istanze di cache di Azure per Redis, leggere da un'istanza

Per questo approccio, è necessario modificare l'applicazione. L'applicazione deve scrivere dati in più istanze della cache durante la lettura da una delle istanze della cache. Questo approccio ha senso se i dati archiviati in cache di Azure per Redis soddisfano i criteri seguenti:

  • I dati vengono aggiornati regolarmente.
  • Tutti i dati vengono scritti nell'istanza di cache di Azure per Redis di destinazione.
  • Tempo sufficiente per l'aggiornamento di tutti i dati.

Per altre informazioni:

PostgreSQL e MySQL

Per altre informazioni, vedere gli articoli nella sezione "Eseguire il backup e la migrazione dei dati" di PostgreSQL e MySQL.

PostgreSQL e MySQL

Passaggi successivi

Informazioni su strumenti, tecniche e consigli per la migrazione delle risorse nelle categorie di servizio seguenti: