Condividi tramite

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

  • Articolo

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo illustra un flusso di lavoro generico per lo spostamento dell’istanza gestita di SQL di Azure in una nuova area.

Nota

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 l’istanza gestita esistente 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.
  6. Rimuovere le risorse dall'area di origine.

Verificare i prerequisiti

  1. Per ogni istanza gestita di origine, crea un'istanza delle stesse dimensioni nell'area obiettivo.
  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 (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 nell’istanza di origine) all’istanza di destinazione e successivamente impostare la chiave come protezione TDE sull'istanza di destinazione, dal momento che adesso un'istanza in un'area può connettersi a un insieme di credenziali delle chiavi in qualsiasi altra area.
    • Come procedura consigliata per assicurarsi che l’istanza di destinazione abbia accesso alle chiavi di crittografia meno recenti (necessarie per il ripristino dei backup del database), esegui il cmdlet Get-AzSqlServerKeyVaultKey nell’istanza di origine o il cmdlet Get-AzSqlInstanceKeyVaultKey nell'istanza gestita di origine per restituire l'elenco delle chiavi disponibili e aggiungere tali chiavi all’istanza di destinazione.
    • Per altre informazioni e procedure consigliate sulla configurazione del TDE gestito dal cliente nell’istanza di destinazione, si veda Transparent Data Encryption di Azure SQL 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

La migrazione di istanze 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 nell’istanza di destinazione, attualmente non possibile.

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 viene avviata automaticamente. Per altre informazioni, vedi Gruppi di failover.

Monitorare il processo di preparazione

È possibile richiamare periodicamente Get-AzSqlDatabaseInstanceFailoverGroup per monitorare la replica dei database dall'origine all’istanza di 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 o ha esito positivo oppure viene eseguito il rollback.
  3. Verificare che il comando sia stato completato correttamente usando nslookup <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 viene 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. Viene interrotta la configurazione del gruppo di failover e vengono 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.

Contenuto correlato