Condividi tramite

Spostare risorse in una nuova area del database SQL di Azure

  • Articolo

Si applica a: Database SQL di Azure

Questo articolo illustra un flusso di lavoro generico per lo spostamento del database o del pool elastico in una nuova area.

Nota

  • Per spostare database e pool elastici in un'area di Azure diversa, è anche possibile usare Spostamento risorse di Azure (consigliato).
  • Questo articolo si applica alle migrazioni all'interno del cloud pubblico di Azure o all'interno dello stesso cloud sovrano.

Panoramica

Esistono vari scenari in cui può essere opportuno spostare il database o il pool 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à.

Il flusso di lavoro generale per spostare le risorse in un'area diversa è 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.

Verificare i prerequisiti per lo spostamento del database

  1. Crea un server di destinazione per ogni server di origine.
  2. Configura il firewall con le eccezioni corrette usando PowerShell.
  3. Configurare entrambi 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, dal momento che un server in un'area può essere collegato a un insieme di credenziali delle chiavi in un'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 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 richiede un traffico tra aree, che non è desiderato o possibile dopo lo spostamento.
  6. Per i controlli a livello di server, accertarsi 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 il server ha un criterio di conservazione a lungo termine (LTR), i backup di conservazione a lungo termine esistenti rimangono associati al server corrente. Poiché il server di destinazione è diverso, è 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

La migrazione di database con backup di conservazione a lungo termine esistenti tra aree sovrane e pubbliche non è supportata poiché richiede lo spostamento di backup con conservazione a lungo termine nel server di destinazione, attualmente non possibile.

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 viene avviata automaticamente. Per altre informazioni, vedi Usare gruppi di failover con database di SQL.

Monitorare il processo di preparazione

È possibile richiamare periodicamente Get-AzSqlDatabaseFailoverGroup per monitorare la replica dei database dall'origine al server di 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 inserito 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.net secondario.
  2. Usare Switch-AzSqlDatabaseFailoverGroup per impostare il server secondario come primario con sincronizzazione completa. Questa operazione avrà esito positivo oppure 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 vengono terminati automaticamente i collegamenti di replica geografica.
  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.

Verificare i prerequisiti per lo spostamento del pool

  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à un traffico tra aree, che non è desiderato o possibile dopo lo spostamento.
  7. Per i controlli a livello di server, accertarsi 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 il server ha un criterio di conservazione a lungo termine (LTR), i backup di conservazione a lungo termine esistenti rimangono associati al server corrente. Poiché il server di destinazione è diverso, è 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

La migrazione di database con backup di conservazione a lungo termine esistenti tra aree sovrane e pubbliche non è supportata poiché richiede lo spostamento di backup con conservazione a lungo termine nel server di destinazione, attualmente non possibile.

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 viene 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 migliora il ridimensionamento e richiede 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 inserito 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 il server secondario come primario con sincronizzazione completa. Questa operazione o ha esito positivo oppure esegue 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 viene 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.

Passaggi successivi

Gestisci il database dopo la migrazione.