Spostare le risorse in una nuova regione - Database SQL di Azure e Istanza gestita di SQL di Azure

  • Articolo

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

Questo articolo illustra un flusso di lavoro generico per lo spostamento del database o dell'istanza gestita in una nuova area.

Panoramica

Esistono vari scenari in cui può essere opportuno spostare il database o l’istanza gestita esistenti da un'area a un'altra. Ad esempio, si espande il lavoro in una nuova area e si vuole ottimizzarla per la nuova base 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 della società.

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

  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 pool elastici e database SQL di Azure in un'area di Azure diversa, puoi anche usare Spostamento risorse di Azure (consigliato). Fare riferimento a questa esercitazione per i passaggi dettagliati per eseguire l’operazione.

Nota

Questo articolo utilizza il modulo Azure Az di PowerShell, che è il modulo di PowerShell consigliato per l'interazione 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. Crea un server di destinazione per ogni server di origine.

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

  3. Configurare i server con gli account di accesso corretti. Se non sei l'amministratore della sottoscrizione o l’amministratore del server SQL, rivolgiti all'amministratore per l'assegnazione delle autorizzazioni necessarie. Per altre informazioni, vedi Come gestire la sicurezza del database SQL di Azure dopo il ripristino di emergenza.

  4. Se i database vengono crittografati con Transparent Data Encryption (TDE) e bring your own encryption key (BYOK o chiave gestita dal cliente) in Azure Key Vault, accertati che venga effettuato il provisioning del materiale di crittografia corretto nelle aree bersaglio.

    • 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 collegata all'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), esegui il cmdlet Get-AzSqlServerKeyVaultKey nel server di origine o il cmdlet Get-AzSqlInstanceKeyVaultKey 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, vedi Transparent Data Encryption di Azure SQL con chiavi gestite dal cliente in Azure Key Vault.
    • Per spostare l'insieme di credenziali delle chiavi nella nuova area, vedi 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, accertati che:

    • Il contenitore di archiviazione, l’analisi dei log o l'hub eventi con i log di controllo esistenti viene spostato nell'area bersaglio.
    • Il controllo è configurato nel server di destinazione. Per altre informazioni, vedi Attività iniziali con il controllo del database SQL.

  7. Se l'istanza ha un criterio di conservazione a lungo termine (LTR), i backup di conservazione a lungo termine esistenti rimarranno associati al server corrente. Poiché il server di destinazione è diverso, potrai accedere ai backup di conservazione a lungo termine meno recenti nell'area di origine usando il server di origine, anche se il server viene eliminato.

    Nota

    Ciò non sarà sufficiente per lo spostamento tra il cloud sovrano e un'area pubblica. Una migrazione di questo tipo richiederà lo spostamento dei backup con conservazione a lungo termine nel server di destinazione, il che non è attualmente supportato.

Preparare le risorse

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

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

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

Monitorare il processo di preparazione

Puoi 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 il failover può essere eseguito in modo sicuro.
  • ReplicationState = 0 (SEEDING) indica che il database non è ancora sottoposto a inserimento nel tabellone e un tentativo di failover avrà esito negativo.

Sincronizzazione di test

Dopo replicationState è 2, collegarsi 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. Collegarsi 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 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 i punti di ingresso DNS CNAME all'indirizzo IP dell'area obiettivo. Se il comando di commutazione non riesce, il 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. Elimina il gruppo di failover usando Remove-AzSqlDatabaseFailoverGroup.
  2. Elimina 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. Elimina 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 Microsoft Entra e altre risorse dipendenti per interrompere la fatturazione.

Spostare pool elastici

Verificare i prerequisiti

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

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

  3. Configurare i server con gli account di accesso corretti. Se non sei l'amministratore della sottoscrizione o ammistratore del server, rivolgersi all'amministratore per l'assegnazione delle autorizzazioni necessarie. Per altre informazioni, vedi Come gestire la sicurezza del database SQL di Azure dopo il ripristino di emergenza.

  4. Se i database vengono crittografati con Transparent Data Encryption e usano la propria chiave di crittografia in Azure Key Vault, assicurarsi che venga effettuato il provisioning del materiale di crittografia corretto nell'area bersaglio.

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

  6. Se è abilitato un controllo a livello di database, 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.

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

    • Il contenitore di archiviazione, l’analisi dei log o l'hub eventi con i log di controllo esistenti viene spostato nell'area bersaglio.
    • La configurazione del controllo è configurata nel server di destinazione. Per altre informazioni, vedi controllo del database SQL.

  8. Se l'istanza ha un criterio di conservazione a lungo termine (LTR), i backup di conservazione a lungo termine esistenti rimarranno associati al server corrente. Poiché il server di destinazione è diverso, sarà possibile accedere ai backup di conservazione a lungo termine meno recenti nell'area di origine usando il server di origine, anche se il server viene eliminato.

    Nota

    Ciò non sarà sufficiente per lo spostamento tra il cloud sovrano e un'area pubblica. Una migrazione di questo tipo richiederà lo spostamento dei backup con conservazione a lungo termine nel server di destinazione, il che non è attualmente supportato.

Preparare lo spostamento

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

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

    La replica dei database aggiunti verrà inizializzata automaticamente. Per altre informazioni, vedi Usare gruppi di failover con database di 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 disponi di un numero grande di database in più pool elastici da spostare, puoi eseguire i passaggi di preparazione in parallelo e quindi avviare il passaggio di spostamento in parallelo. Questo processo migliorerà il ridimensionamento e richiederà meno tempo rispetto alla presenza di più pool elastici nello stesso gruppo di failover.

Monitorare il processo di preparazione

Puoi 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 il failover può essere eseguito in modo sicuro.
  • ReplicationState = 0 (SEEDING) indica che il database non è ancora sottoposto a inserimento nel tabellone e un tentativo di failover avrà esito negativo.

Sincronizzazione di test

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

Avviare lo spostamento

  1. Collegarsi al server di destinazione usando l'endpoint <fog-name>.secondary.database.windows.net secondario.
  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 i punti di ingresso DNS CNAME all'indirizzo IP dell'area obiettivo. Se il comando di commutazione 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. Elimina il gruppo di failover usando Remove-AzSqlDatabaseFailoverGroup.
  2. Elimina ogni pool elastico di origine nel server di origine usando Remove-AzSqlElasticPool.
  3. Elimina il server di origine usando Remove-AzSqlServer.
  4. Rimuovi l'insieme di credenziali delle chiavi, controlla i contenitori di archiviazione, l'hub eventi, il tenant di Microsoft Entra e altre risorse dipendenti per interrompere la fatturazione.

Spostare un’istanza gestita

Verificare i prerequisiti

  1. Per ogni istanza gestita di origine, crea un'istanza di destinazione di Istanza gestita di SQL delle stesse dimensioni nell'area bersaglio.
  2. Configura la rete per un'istanza gestita. Per altre informazioni, vedi configurazione della rete.
  3. Configura il database bersaglio master con gli account di accesso corretti. Se non sei l'amministratore della sottoscrizione dell’istanza gestita di SQL, rivolgitii all'amministratore per l'assegnazione delle autorizzazioni necessarie.
  4. Se i database vengono crittografati con Transparent Data Encryption e usano la propria chiave di crittografia in Azure Key Vault, accertati che Azure Key Vault con chiavi di crittografia identiche esista nelle aree di origine e di destinazione. Per altre informazioni, vedi Transparent Data Encryption con chiavi gestite dal cliente in Azure Key Vault.
  5. Se il controllo è abilitato per l'istanza gestita, verifica che:
    • Il contenitore di archiviazione o l'hub eventi con i log esistenti viene spostato nell'area bersaglio.
    • Il controllo è configurato nell'istanza bersaglio. Per altre informazioni, vedi Controllo con istanza gestita di SQL.
  6. Se l'istanza ha 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, potrai accedere ai backup di conservazione a lungo termine 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. Una migrazione di questo tipo richiederà lo spostamento dei backup di conservazione a lungo termine nell'istanza bersaglio, che non è attualmente supportata.

Preparare le risorse

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

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

Monitorare il processo di preparazione

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

  • ReplicationState = CATCH_UP indica che il database è sincronizzato e il failover può essere eseguito in modo sicuro.
  • ReplicationState = SEEDING indica che il database non è ancora inserito nel tabellone e un tentativo di failover avrà esito negativo.

Sincronizzazione di test

Quando ReplicationState è CATCH_UP, collegati alla replica geografica secondaria usando l'endpoint <fog-name>.secondary.<zone_id>.database.windows.net secondario ed esegui qualsiasi query sui database per garantire la connettività, la configurazione di sicurezza appropriata e la replica dei dati.

Avviare lo spostamento

  1. Collegati all'istanza gestita bersaglio usando l'endpoint <fog-name>.secondary.<zone_id>.database.windows.net secondario.
  2. Usa Switch-AzSqlDatabaseInstanceFailoverGroup 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.<zone_id>.database.windows.net per verificare che i punti di ingresso DNS CNAME all'indirizzo IP dell'area obiettivo. Se il comando di commutazione non riesce, il CNAME non verrà aggiornato.

Rimuovere le istanze gestite di origine

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

  1. Elimina il gruppo di failover usando Remove-AzSqlDatabaseInstanceFailoverGroup. Verrà interrotta la configurazione del gruppo di failover e verranno terminati i collegamenti di replica geografica tra le due istanze.
  2. Elimina l'istanza gestita di origine usando Remove-AzSqlInstance.
  3. Rimuovi tutte le risorse aggiuntive nel gruppo di risorse, ad esempio la rete virtuale e il gruppo di sicurezza.

Passaggi successivi

Gestisci il database dopo la migrazione.