Spostare le risorse in una nuova area : Azure SQL Database & Istanza gestita di SQL di Azure

Si applica a: Database SQL di Azure Istanza gestita di SQL di Azure

Questo articolo illustra un flusso di lavoro generico per come spostare il database o l'istanza gestita in una nuova area.

Panoramica

Esistono vari scenari in cui si vuole spostare il database esistente o l'istanza gestita da un'area a un'altra. Ad esempio, si espande l'azienda in una nuova area e si vuole ottimizzarla per la nuova base dei clienti. Oppure è necessario spostare le operazioni in un'area diversa per motivi di conformità. In alternativa, Azure ha rilasciato una nuova area che offre una maggiore prossimità e migliora l'esperienza del cliente.

Questo articolo fornisce un flusso di lavoro generale per lo spostamento delle risorse in un'area diversa. Il flusso di lavoro è costituito dai passaggi seguenti:

  1. Verificare i prerequisiti per lo spostamento.
  2. Preparare lo spostamento delle risorse nell'ambito.
  3. Monitorare il processo di preparazione.
  4. Testare il processo di spostamento.
  5. Avviare lo spostamento effettivo.
  6. Rimuovere le risorse dall'area di origine.

Nota

Questo articolo si applica alle migrazioni all'interno del cloud pubblico di Azure o all'interno dello stesso cloud sovrano.

Nota

Per spostare Azure SQL database e pool elastici in un'area di Azure diversa, è anche possibile usare Azure Resource Mover (scelta consigliata). Vedere questa esercitazione per i passaggi dettagliati per eseguire la stessa operazione.

Nota

Questo articolo usa il modulo Azure Az PowerShell, che è il modulo PowerShell consigliato per interagire con Azure. Per iniziare a usare il modulo Az PowerShell, 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.

Spostare un database

Verificare i prerequisiti

  1. Creare un server di destinazione per ogni server di origine.

  2. Configurare il firewall con le eccezioni corrette usando PowerShell.

  3. Configurare i server con gli account di accesso corretti. Se non si è l'amministratore della sottoscrizione o l'amministratore di SQL Server, collaborare con l'amministratore per assegnare le autorizzazioni necessarie. Per altre informazioni, vedere Come gestire la sicurezza del database Azure SQL dopo il ripristino di emergenza.

  4. Se i database vengono crittografati con la crittografia dei dati trasparente (TDE) e porterà la propria chiave di crittografia (BYOK o chiave di Customer-Managed) in Azure Key Vault, assicurarsi che il materiale di crittografia corretto venga effettuato nel provisioning nelle aree di destinazione.

    • Il modo più semplice per eseguire questa operazione consiste nell'aggiungere la chiave di crittografia dall'insieme di credenziali delle chiavi esistente (usato come protezione TDE nel server di origine) al server di destinazione e quindi impostare la chiave come protezione TDE nel server di destinazione

      Nota

      Un server o un'istanza gestita in un'area può ora essere connessa a un insieme di credenziali delle chiavi in qualsiasi altra area.

    • Come procedura consigliata per assicurarsi che il server di destinazione abbia accesso alle chiavi di crittografia meno recenti (necessarie per il ripristino dei backup del database), eseguire il cmdlet Get-AzSqlServerKeyVaultKey nel server di origine o Get-AzSqlInstanceKeyKeykey nell'istanza gestita di origine per restituire l'elenco delle chiavi disponibili e aggiungere tali chiavi al server di destinazione.
    • Per altre informazioni e procedure consigliate sulla configurazione del TDE gestito dal cliente nel server di destinazione, vedere Azure SQL la crittografia dei dati trasparente con chiavi gestite dal cliente in Azure Key Vault.
    • Per spostare l'insieme di credenziali delle chiavi nella nuova area, vedere Spostare un insieme di credenziali delle chiavi di Azure tra aree
  5. Se il controllo a livello di database è abilitato, disabilitarlo e abilitare invece il controllo a livello di server. Dopo il failover, il controllo a livello di database richiederà il traffico tra aree, che non è desiderato o possibile dopo lo spostamento.

  6. Per i controlli a livello di server, assicurarsi che:

    • Il contenitore di archiviazione, Log Analytics o l'hub eventi con i log di controllo esistenti viene spostato nell'area di destinazione.
    • Il controllo è configurato nel server di destinazione. Per altre informazioni, vedere Introduzione al controllo database SQL.
  7. Se l'istanza ha un criterio di conservazione a lungo termine (LTR), i backup LTR esistenti rimarranno associati al server corrente. Poiché il server di destinazione è diverso, sarà possibile accedere ai backup LTR meno recenti nell'area di origine usando il server di origine, anche se il server di origine viene eliminato.

    Nota

    Ciò sarà insufficiente per lo spostamento tra il cloud sovrano e un'area pubblica. Tale migrazione richiederà lo spostamento dei backup LTR nel server di destinazione, che non è attualmente supportato.

Preparare le risorse

  1. Creare un gruppo di failover tra il server dell'origine e il server della destinazione.

  2. Aggiungere i database da spostare nel gruppo di failover.

    La replica di tutti i database aggiunti verrà avviata automaticamente. Per altre informazioni, vedere Uso dei gruppi di failover con database SQL.

Monitorare il processo di preparazione

È possibile chiamare periodicamente Get-AzSqlDatabaseFailoverGroup per monitorare la replica dei database dall'origine alla destinazione. L'oggetto output di Get-AzSqlDatabaseFailoverGroup include una proprietà per ReplicationState:

  • ReplicationState = 2 (CATCH_UP) indica che il database è sincronizzato e può essere eseguito in modo sicuro.
  • ReplicationState = 0 (SEEDING) indica che il database non è ancora stato inizializzato e un tentativo di failover avrà esito negativo.

Sincronizzazione dei test

Dopo che ReplicationState è 2, connettersi a ogni database o sottoinsieme di database usando l'endpoint <fog-name>.secondary.database.windows.net secondario ed eseguire qualsiasi query sui database per garantire la connettività, la configurazione di sicurezza appropriata e la replica dei dati.

Avviare lo spostamento

  1. Connettersi al server di destinazione usando l'endpoint <fog-name>.secondary.database.windows.netsecondario .
  2. Usare Switch-AzSqlDatabaseFailoverGroup per cambiare l'istanza gestita secondaria in modo che sia primaria con sincronizzazione completa. Questa operazione avrà esito positivo o verrà eseguito il rollback.
  3. Verificare che il comando sia stato completato correttamente usando nslook up <fog-name>.secondary.database.windows.net per verificare che la voce DNS CNAME punti all'indirizzo IP dell'area di destinazione. Se il comando switch ha esito negativo, il nome CNAME non verrà aggiornato.

Rimuovere i database di origine

Al termine dello spostamento, rimuovere le risorse nell'area di origine per evitare addebiti non necessari.

  1. Eliminare il gruppo di failover usando Remove-AzSqlDatabaseFailoverGroup.
  2. Eliminare ogni database di origine usando Remove-AzSqlDatabase per ognuno dei database nel server di origine. In questo modo verranno terminati automaticamente i collegamenti di replica geografica.
  3. Eliminare il server di origine usando Remove-AzSqlServer.
  4. Rimuovere l'insieme di credenziali delle chiavi, controllare i contenitori di archiviazione, l'hub eventi, l'istanza di Azure Active Directory (Azure AD) e altre risorse dipendenti per interrompere la fatturazione.

Spostare pool elastici

Verificare i prerequisiti

  1. Creare un server di destinazione per ogni server di origine.

  2. Configurare il firewall con le eccezioni corrette usando PowerShell.

  3. Configurare i server con gli account di accesso corretti. Se non si è l'amministratore della sottoscrizione o l'amministratore del server, collaborare con l'amministratore per assegnare le autorizzazioni necessarie. Per altre informazioni, vedere Come gestire la sicurezza del database Azure SQL dopo il ripristino di emergenza.

  4. Se i database vengono crittografati con la crittografia dei dati trasparente e usano la propria chiave di crittografia in Azure Key Vault, assicurarsi che il materiale di crittografia corretto venga effettuato nel provisioning nell'area di destinazione.

  5. Creare un pool elastico di destinazione per ogni pool elastico di origine, assicurandosi che il pool venga creato nello stesso livello di servizio, con lo stesso nome e le stesse dimensioni.

  6. Se invece è abilitato un controllo a livello di database, disabilitarlo e abilitare il controllo a livello di server. Dopo il failover, il controllo a livello di database richiederà il traffico tra aree, che non è desiderato o possibile dopo lo spostamento.

  7. Per i controlli a livello di server, assicurarsi che:

    • Il contenitore di archiviazione, Log Analytics o l'hub eventi con i log di controllo esistenti viene spostato nell'area di destinazione.
    • La configurazione di controllo è configurata nel server di destinazione. Per altre informazioni, vedere database SQL controllo.
  8. Se l'istanza ha un criterio di conservazione a lungo termine (LTR), i backup LTR esistenti rimarranno associati al server corrente. Poiché il server di destinazione è diverso, sarà possibile accedere ai backup LTR meno recenti nell'area di origine usando il server di origine, anche se il server viene eliminato.

    Nota

    Ciò sarà insufficiente per lo spostamento tra il cloud sovrano e un'area pubblica. Tale migrazione richiederà lo spostamento dei backup LTR nel server di destinazione, che non è attualmente supportato.

Preparare lo spostamento

  1. Creare un gruppo di failover separato tra ogni pool elastico nel server di origine e il pool elastico della controparte nel server di destinazione.

  2. Aggiungere tutti i database nel pool al gruppo di failover.

    La replica dei database aggiunti verrà avviata automaticamente. Per altre informazioni, vedere Uso di gruppi di failover con database SQL.

    Nota

    Sebbene sia possibile creare un gruppo di failover che includa più pool elastici, è consigliabile creare un gruppo di failover separato per ogni pool. Se si dispone di un numero elevato di database in più pool elastici da spostare, è possibile eseguire i passaggi di preparazione in parallelo e quindi avviare il passaggio di spostamento in parallelo. Questo processo migliorerà e richiederà meno tempo rispetto alla presenza di più pool elastici nello stesso gruppo di failover.

Monitorare il processo di preparazione

È possibile chiamare periodicamente Get-AzSqlDatabaseFailoverGroup per monitorare la replica dei database dall'origine alla destinazione. L'oggetto di output di Get-AzSqlDatabaseFailoverGroup include una proprietà per ReplicationState:

  • ReplicationState = 2 (CATCH_UP) indica che il database è sincronizzato e può essere eseguito in modo sicuro il failover.
  • ReplicationState = 0 (SEEDING) indica che il database non è ancora sottoposto a seeding e un tentativo di failover avrà esito negativo.

Testare la sincronizzazione

Quando ReplicationState è 2, connettersi a ogni database o sottoinsieme di database usando l'endpoint <fog-name>.secondary.database.windows.net secondario ed eseguire qualsiasi query sui database per garantire la connettività, la configurazione di sicurezza appropriata e la replica dei dati.

Avviare lo spostamento

  1. Connettersi al server di destinazione usando l'endpoint <fog-name>.secondary.database.windows.netsecondario .
  2. Usare Switch-AzSqlDatabaseFailoverGroup per impostare l'istanza gestita secondaria come primaria con sincronizzazione completa. Questa operazione avrà esito positivo oppure eseguirà il rollback.
  3. Verificare che il comando sia stato completato correttamente usando nslook up <fog-name>.secondary.database.windows.net per verificare che la voce DNS CNAME punti all'indirizzo IP dell'area di destinazione. Se il comando switch non riesce, il CNAME non verrà aggiornato.

Rimuovere i pool elastici di origine

Al termine dello spostamento, rimuovere le risorse nell'area di origine per evitare addebiti non necessari.

  1. Eliminare il gruppo di failover usando Remove-AzSqlDatabaseFailoverGroup.
  2. Eliminare ogni pool elastico di origine nel server di origine usando Remove-AzSqlElasticPool.
  3. Eliminare il server di origine usando Remove-AzSqlServer.
  4. Rimuovere l'insieme di credenziali delle chiavi, controllare i contenitori di archiviazione, l'hub eventi, l'istanza di Azure AD e altre risorse dipendenti per interrompere la fatturazione.

Spostare un'istanza gestita

Verificare i prerequisiti

  1. Per ogni istanza gestita di origine, creare un'istanza di destinazione di Istanza gestita di SQL delle stesse dimensioni nell'area di destinazione.
  2. Configurare la rete per un'istanza gestita. Per altre informazioni, vedere Configurazione di rete.
  3. Configurare il database master di destinazione con gli account di accesso corretti. Se non si è la sottoscrizione o l'amministratore di Istanza gestita di SQL, rivolgersi all'amministratore per assegnare le autorizzazioni necessarie.
  4. Se i database vengono crittografati con Transparent Data Encryption e usano la propria chiave di crittografia in Azure Key Vault, assicurarsi che l'Key Vault di Azure con chiavi di crittografia identiche esista sia nelle aree di origine che in quella di destinazione. Per altre informazioni, vedere Transparent Data Encryption con chiavi gestite dal cliente in Azure Key Vault.
  5. Se il controllo è abilitato per l'istanza gestita, assicurarsi che:
    • Il contenitore di archiviazione o l'hub eventi con i log esistenti viene spostato nell'area di destinazione.
    • Il controllo viene configurato nell'istanza di destinazione. Per altre informazioni, vedere Controllo con Istanza gestita di SQL.
  6. Se l'istanza dispone di un criterio di conservazione a lungo termine (LTR), i backup di conservazione a lungo termine esistenti rimarranno associati all'istanza corrente. Poiché l'istanza di destinazione è diversa, sarà possibile accedere ai backup LTR meno recenti nell'area di origine usando l'istanza di origine, anche se l'istanza viene eliminata.

Nota

Ciò non sarà sufficiente per lo spostamento tra il cloud sovrano e un'area pubblica. Questa migrazione richiederà lo spostamento dei backup di conservazione a lungo termine nell'istanza di destinazione, che non è attualmente supportata.

Preparare le risorse

Creare un gruppo di failover tra ogni istanza gestita di origine e l'istanza di destinazione corrispondente di Istanza gestita di SQL.

La replica di tutti i database in ogni istanza verrà avviata automaticamente. Per altre informazioni, vedere Gruppi di failover automatico.

Monitorare il processo di preparazione

È possibile chiamare periodicamente Get-AzSqlDatabaseFailoverGroup per monitorare la replica dei database dall'origine alla destinazione. L'oggetto di output di Get-AzSqlDatabaseFailoverGroup include una proprietà per ReplicationState:

  • ReplicationState = 2 (CATCH_UP) indica che il database è sincronizzato e può essere eseguito in modo sicuro il failover.
  • ReplicationState = 0 (SEEDING) indica che il database non è ancora sottoposto a seeding e un tentativo di failover avrà esito negativo.

Testare la sincronizzazione

Quando ReplicationState è 2, connettersi a ogni database o sottoinsieme di database usando l'endpoint <fog-name>.secondary.database.windows.net secondario ed eseguire qualsiasi query sui database per garantire la connettività, la configurazione di sicurezza appropriata e la replica dei dati.

Avviare lo spostamento

  1. Connettersi all'istanza gestita di destinazione usando l'endpoint <fog-name>.secondary.database.windows.netsecondario .
  2. Usare Switch-AzSqlDatabaseFailoverGroup per impostare l'istanza gestita secondaria come primaria con sincronizzazione completa. Questa operazione avrà esito positivo oppure eseguirà il rollback.
  3. Verificare che il comando sia stato completato correttamente usando nslook up <fog-name>.secondary.database.windows.net per verificare che la voce DNS CNAME punti all'indirizzo IP dell'area di destinazione. Se il comando switch non riesce, il CNAME non verrà aggiornato.

Rimuovere le istanze gestite di origine

Al termine dello spostamento, rimuovere le risorse nell'area di origine per evitare addebiti non necessari.

  1. Eliminare il gruppo di failover usando Remove-AzSqlDatabaseFailoverGroup. In questo modo la configurazione del gruppo di failover verrà interrotta e verranno terminati i collegamenti di replica geografica tra le due istanze.
  2. Eliminare l'istanza gestita di origine usando Remove-AzSqlInstance.
  3. Rimuovere tutte le risorse aggiuntive nel gruppo di risorse, ad esempio il cluster virtuale, la rete virtuale e il gruppo di sicurezza.

Passaggi successivi

Gestire il database dopo la migrazione.