Dela via

Flytta resurser till en ny region – Azure SQL Managed Instance

  • Artikel

gäller för:Azure SQL Managed Instance

I den här artikeln får du lära dig ett allmänt arbetsflöde för hur du flyttar Azure SQL Managed Instance till en ny region.

Not

Den här artikeln gäller migreringar i det offentliga Azure-molnet eller i samma nationella moln.

Överblick

Det finns olika scenarier där du vill flytta din befintliga hanterade instans från en region till en annan. Du expanderar till exempel ditt företag till en ny region och vill optimera det för den nya kundbasen. Eller så måste du flytta åtgärderna till en annan region av efterlevnadsskäl. Eller så släppte Azure en ny region som ger en bättre närhet och förbättrar kundupplevelsen.

Det allmänna arbetsflödet för att flytta resurser till en annan region består av följande steg:

  1. Kontrollera förutsättningarna för flytten.
  2. Förbered att flytta resurserna inom omfattningen.
  3. Övervaka förberedelseprocessen.
  4. Testa flyttprocessen.
  5. Initiera den faktiska flytten.
  6. Ta bort resurserna från källregionen.

Verifiera förutsättningar

  1. För varje källhanterad instans skapar du en instans av samma storlek i målregionen.
  2. Konfigurera nätverket för en hanterad instans. Mer information finns i nätverkskonfiguration.
  3. Konfigurera måldatabasen master med rätt inloggningar. Om du inte är prenumerations- eller SQL Managed Instance-administratör kan du kontakta administratören för att tilldela de behörigheter som du behöver.
  4. Om dina databaser krypteras med transparent datakryptering (TDE) och tar med din egen krypteringsnyckel (BYOK eller Customer-Managed Key) i Azure Key Vault kontrollerar du att rätt krypteringsmaterial etableras i målregionerna.
    • Det enklaste sättet att göra detta är att lägga till krypteringsnyckeln från det befintliga nyckelvalvet (som används som TDE-skydd på källinstansen) till målinstansen och sedan ange nyckeln som TDE-skydd på målinstansen eftersom en instans i en region nu kan ansluta till ett nyckelvalv i någon annan region.
    • Som bästa praxis för att säkerställa att målinstansen har åtkomst till äldre krypteringsnycklar (krävs för att återställa databassäkerhetskopior) kör du cmdleten Get-AzSqlServerKeyVaultKey cmdlet på källinstansen eller Get-AzSqlInstanceKeyVaultKey cmdlet på den källhanterade instansen för att returnera listan över tillgängliga nycklar och lägga till nycklarna i målinstansen.
    • Mer information och metodtips för att konfigurera kundhanterad TDE på målinstansen finns i transparent datakryptering i Azure SQL med kundhanterade nycklar i Azure Key Vault.
  5. Om granskning är aktiverat för den hanterade instansen kontrollerar du att:
    • Lagringscontainern eller händelsehubben med befintliga loggar flyttas till målregionen.
    • Granskning konfigureras på målinstansen. Mer information finns i Revision med SQL Managed Instance.
  6. Om din instans har en långsiktig kvarhållningsprincip (LTR) förblir de befintliga LTR-säkerhetskopiorna associerade med den aktuella instansen. Eftersom målinstansen är annorlunda kan du komma åt de äldre LTR-säkerhetskopiorna i källregionen med hjälp av källinstansen, även om instansen tas bort.

Notera

Migrering av instanser med befintliga LTR-säkerhetskopior mellan nationella och offentliga regioner stöds inte eftersom detta kräver att LTR-säkerhetskopior flyttas till målinstansen, vilket för närvarande inte är möjligt.

Förbereda resurser

Skapa en redundansgrupp mellan varje källhanterad instans och motsvarande målinstans för SQL Managed Instance.

Replikering av alla databaser på varje instans initieras automatiskt. Mer information finns i redundansgrupper.

Övervaka förberedelseprocessen

Du kan regelbundet anropa Get-AzSqlDatabaseInstanceFailoverGroup för att övervaka replikeringen av dina databaser från källan till målinstansen. Utdataobjektet för Get-AzSqlDatabaseInstanceFailoverGroup innehåller en egenskap för ReplicationState:

  • ReplicationState = CATCH_UP anger att databasen är synkroniserad och kan växlas över på ett säkert sätt.
  • ReplicationState = SEEDING anger att databasen ännu inte är seedad och att ett redundansförsök misslyckas.

Testsynkronisering

När ReplicationState är CATCH_UP, anslut till den geo-sekundära med hjälp av den sekundära slutpunkten <fog-name>.secondary.<zone_id>.database.windows.net och utför någon fråga mot databaserna för att säkerställa anslutning, korrekt säkerhetskonfiguration och datareplikering.

Initiera flytten

  1. Anslut till den hanterade målinstansen med hjälp av den sekundära slutpunkten <fog-name>.secondary.<zone_id>.database.windows.net.
  2. Använd Switch-AzSqlDatabaseInstanceFailoverGroup för att växla den sekundära hanterade instansen till den primära med fullständig synkronisering. Den här åtgärden lyckas eller går tillbaka.
  3. Kontrollera att kommandot har slutförts framgångsrikt genom att använda nslookup <fog-name>.secondary.<zone_id>.database.windows.net för att säkerställa att DNS CNAME-posten pekar på IP-adressen för målregionen. Om växelkommandot misslyckas uppdateras inte CNAME.

Ta bort källhanterade instanser

När flytten är klar tar du bort resurserna i källregionen för att undvika onödiga avgifter.

  1. Ta bort failover-gruppen med hjälp av Remove-AzSqlDatabaseInstanceFailoverGroup. Detta tar bort konfigurationen av failovergruppen och avslutar geo-replikeringslänkarna mellan de två instanserna.
  2. Ta bort den källhanterade instansen med hjälp av Remove-AzSqlInstance-.
  3. Ta bort eventuella ytterligare resurser i resursgruppen, till exempel det virtuella nätverket och säkerhetsgruppen.

Relaterat innehåll