Dela via


Förbered din miljö för en länk – Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

I den här artikeln lär du dig hur du förbereder din miljö för en Managed Instance-länk så att du kan replikera mellan SQL Server som installerats för att Windows eller Linux och Azure SQL Managed Instance.

Anmärkning

Du kan automatisera förberedelsen av miljön för länken Managed Instance med hjälp av ett nedladdningsbart skript. För mer information, se bloggen om att automatisera länkuppsättning.

Förutsättningar

Om du vill skapa en länk mellan SQL Server och Azure SQL Managed Instance behöver du följande förutsättningar:

  • En aktiv prenumeration för Azure. Om du inte har ett, skapa ett kostnadsfritt konto.
  • En Supported-version av SQL Server med nödvändig tjänstuppdatering.
  • Azure SQL Managed Instance med en lämplig uppdateringspolicy. Kom igång om du inte har någon.
  • En server som du tänker vara den första primära. Det här valet avgör var du ska skapa länken från.
    • Att konfigurera en länk från en SQL Managed Instance primär till en sekundär SQL Server 2025 stöds endast med SQL-hanterade instanser som konfigurerats med SQL Server 2025-uppdateringsprincipen.
    • Det är endast möjligt att konfigurera en länk från en primär SQL Managed Instance till en sekundär SQL Server 2022 från och med SQL Server 2022 CU10 och med SQL-hanterade instanser som är konfigurerade enligt uppdateringsprincipen för SQL Server 2022.

Försiktighet

När du skapar din SQL-hanterade instans som ska användas med länkfunktionen ska du ta hänsyn till minneskraven för alla In-Memory OLTP-funktioner (onlinetransaktionsbearbetning) SQL Server använder. Mer information finns i Översikt över Azure SQL Managed Instance resursgränser.

Permissions

För SQL Server bör du ha behörigheterna sysadmin.

För Azure SQL Managed Instance bör du vara medlem i SQL Managed Instance Deltagare eller ha följande behörigheter för en anpassad roll:

Microsoft.Sql/resurs Nödvändiga behörigheter
Microsoft.Sql/managedInstances /läsa, /skriva
Microsoft.Sql/managedInstances/hybridCertificate /åtgärd
Microsoft.Sql/managedInstances/databaser /läsa, /ta bort, /skriva, /fullständigÅterställning/åtgärd, /läsSäkerhetskopior/åtgärd, /återställningsdetaljer/läsa
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /läs, /skriv, /radera, /sättRoll/åtgärd
Microsoft.Sql/managedInstances/endpointCertificates /läsa
Microsoft.Sql/managedInstances/hybridLink /läsa, /skriva, /ta bort
Microsoft. Sql/managedInstances/serverTrustCertificates /skriv, /ta bort, /läs

Matcha prestandakapacitet mellan repliker

När du använder länkfunktionen är det viktigt att matcha prestandakapaciteten mellan SQL Server och SQL Managed Instance. Den här matchningen hjälper dig att undvika prestandaproblem om den sekundära repliken inte kan hänga med i replikeringen från den primära repliken eller efter redundansväxlingen. Prestandakapaciteten omfattar processorkärnor (eller virtuella kärnor i Azure), minne och I/O-dataflöde.

Förbereda din SQL Server-instans

För att förbereda din SQL Server-instans måste du verifiera att:

Du måste starta om SQL Server för att ändringarna ska börja gälla.

Installera tjänstuppdateringar

Se till att din SQL Server version har rätt underhållsuppdatering installerad, enligt listan i tabellen versionssupport. Om du behöver installera uppdateringar måste du starta om din SQL Server instans under uppdateringen.

Om du vill kontrollera din SQL Server-version kör du följande Transact-SQL-skript (T-SQL) på SQL Server:

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Skapa en huvudnyckel för databasen i huvuddatabasen

Länken använder certifikat för att kryptera autentisering och kommunikation mellan SQL Server och SQL Managed Instance. Databasens huvudnyckel skyddar de certifikat som används av länken. Om du redan har en huvudnyckel för databasen kan du hoppa över det här steget.

Skapa databashuvudnyckeln master i databasen. Infoga lösenordet i stället för <strong_password> i följande skript och förvara det på en konfidentiell och säker plats. Kör det här T-SQL-skriptet på SQL Server:

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Kontrollera att du har databashuvudnyckeln genom att använda följande T-SQL-skript på SQL Server:

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Aktivera tillgänglighetsgrupper

Länkfunktionen förlitar sig på funktionen AlwaysOn-tillgänglighetsgrupper, som är inaktiverad som standard. Mer information finns i avsnittet Aktivera Always On-tillgänglighetsgruppsfunktionen.

Anmärkning

Information om SQL Server on Linux finns i Enable AlwaysOn-tillgänglighetsgrupper.

Kontrollera att funktionen tillgänglighetsgrupper är aktiverad genom att köra följande T-SQL-skript på SQL Server:

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Viktigt!

Om du behöver aktivera funktionen för tillgänglighetsgrupper i SQL Server 2016 (13.x) måste du slutföra de extra stegen som beskrivs i Förbered SQL Server 2016 förutsättningar - länken 'Azure SQL Managed Instance'. De här extra stegen krävs inte för SQL Server 2017 (14.x) och senare versioner som stöds av länken.

Om funktionen tillgänglighetsgrupper inte är aktiverad följer du de här stegen för att aktivera den:

  1. Öppna SQL Server Configuration Manager.

  2. Välj SQL Server Services i det vänstra fönstret.

  3. Högerklicka på tjänsten SQL Server och välj sedan Egenskaper.

    Screenshot som visar SQL Server Configuration Manager, med val för att öppna egenskaper för tjänsten.

  4. Gå till fliken Always On- tillgänglighetsgrupper.

  5. Markera kryssrutan Aktivera AlwaysOn-tillgänglighetsgrupper och välj sedan OK.

    Skärmbild som visar egenskaperna för AlwaysOn-tillgänglighetsgrupper.

    • Om du använder SQL Server 2016 (13.x) och om alternativet Aktivera Always On Availability Groups är inaktiverat med ett meddelande This computer is not a node in a failover cluster, följ de extra stegen som beskrivs i Förbered SQL Server 2016 förutsättningar - Azure SQL Managed Instance. När du har slutfört de här andra stegen kan du komma tillbaka och försöka utföra det här steget igen.
  6. Välj OK i dialogrutan.

  7. Starta om SQL Server-tjänsten.

Aktivera spårningsflaggor vid uppstart

För att optimera prestanda för länken rekommenderar vi att du aktiverar följande spårningsflaggor vid start:

  • -T1800: Den här spårningsflaggan optimerar prestanda när loggfilerna för de primära och sekundära replikerna i en tillgänglighetsgrupp finns på diskar med olika sektorstorlekar, till exempel 512 byte och 4 KB. Om både primära och sekundära repliker har en disksektorstorlek på 4 KB krävs inte den här spårningsflaggan. Mer information finns i KB3009974.
  • -T9567: Den här spårningsflaggan möjliggör komprimering av dataströmmen för tillgänglighetsgrupper under automatisk seeding. Komprimering ökar belastningen på processorn men kan avsevärt minska överföringstiden under seeding.

Anmärkning

För SQL Server på Linux, se Enable trace flags.

Använd följande steg för att aktivera dessa spårningsflaggor vid start:

  1. Öppna SQL Server Configuration Manager.

  2. Välj SQL Server Services i det vänstra fönstret.

  3. Högerklicka på tjänsten SQL Server och välj sedan Egenskaper.

    Screenshot som visar SQL Server Configuration Manager.

  4. Gå till fliken Startparametrar . I Ange en startparameter anger -T1800 du och väljer Lägg till för att lägga till startparametern. Ange -T9567 sedan och välj Lägg till för att lägga till den andra spårningsflaggan. Tryck på Apply (Verkställ) för att spara ändringarna.

    Skärmbild som visar egenskaper för startparametrar.

  5. Välj OK för att stänga fönstret Egenskaper .

Mer information finns i syntaxen för att aktivera spårningsflaggor.

Använda säkerhetskopior med kontrollsummor

När du skapar en länk görs den första seedningen mellan de primära och sekundära replikerna genom att ta en fullständig säkerhetskopia av databasen på den primära repliken, överföra den till den sekundära repliken och återställa den där. När du gör den fullständiga säkerhetskopieringen WITH CHECKSUM rekommenderar vi att du använder alternativet för att säkerställa att säkerhetskopian är giltig och inte har några skador. Mer information finns i BACKUP (Transact-SQL).

Starta om SQL Server och verifiera konfigurationen

När du har sett till att du har en version av SQL Server som stöds, aktiverat funktionen AlwaysOn-tillgänglighetsgrupper och lagt till startspårningsflaggor startar du om SQL Server-instansen för att tillämpa alla dessa ändringar:

  1. Öppna SQL Server Configuration Manager.

  2. Välj SQL Server Services i det vänstra fönstret.

  3. Högerklicka på tjänsten SQL Server och välj sedan Restart.

    Screenshot som visar kommandoanropet SQL Server omstart.

Efter omstarten kör du följande T-SQL-skript på SQL Server för att verifiera konfigurationen av din SQL Server-instans:

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

Din SQL Server version bör vara en av de versioner som stöds med lämpliga tjänstuppdateringar, funktionen AlwaysOn-tillgänglighetsgrupper ska vara aktiverad och du bör ha spårningsflaggorna -T1800 och -T9567 aktiverade. Följande skärmbild är ett exempel på det förväntade resultatet för en korrekt konfigurerad SQL Server instans:

Skärmbild som visar det förväntade resultatet i SSMS.

Aktivera accelererad databasåterställning

För SQL Server 2019 och senare versioner aktiverar du accelerated database recovery och kontrollerar att det beständiga versionsarkivet (PVS) är inställt på PRIMARY. Om accelererad databasåterställning inte är aktiverad på källdatabasen SQL Server kan du inte aktivera den på sql-målhanterad instans när databasen har migrerats. Om det beständiga versionsarkivet (PVS) inte är inställt PRIMARYpå kan du få problem med återställningsåtgärder på den sql-hanterade målinstansen.

För SQL Server 2017 och tidigare versioner stöds inte accelererad databasåterställning, så det här steget är inte nödvändigt.

Följ dessa steg för att konfigurera accelererad databasåterställning korrekt på källdatabasen SQL Server:

  1. Aktivera accelererad databasåterställning genom att köra följande Transact-SQL skript på SQL Server:

    ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
    
  2. Det beständiga versionsarkivet (PVS) måste anges till PRIMARY på källdatabasen, vilket är standardkonfigurationen. Om detta ändrades tidigare måste du ändra tillbaka det till PRIMÄR innan du påbörjar migreringen.

Aktivera Service Broker

Service Broker är aktiverat som standard för alla versioner av SQL Server. Om Service Broker har inaktiverats och du planerar att använda den på SQL Managed Instance aktiverar du Service Broker på källdatabasen SQL Server innan du migrerar till SQL Managed Instance. Om Service Broker inte är aktiverat på källdatabasen SQL Server kan du inte använda den på den sql-hanterade målinstansen.

Kontrollera om Service Broker är aktiverat genom att köra följande Transact-SQL skript på SQL Server instans:

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Om Service Broker är inaktiverat aktiverar du det genom att köra följande Transact-SQL skript på källdatabasen SQL Server:

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Konfigurera nätverksanslutning

För att länken ska fungera måste du ha nätverksanslutning mellan SQL Server och SQL Managed Instance. Vilket nätverksalternativ du väljer beror på om din SQL Server instans finns i ett Azure nätverk eller inte.

SQL Server på Azure Virtual Machines

Att distribuera SQL Server på Azure Virtual Machines i samma Azure virtuella nätverk som är värd för SQL Managed Instance är den enklaste metoden, eftersom nätverksanslutningen automatiskt finns mellan de två instanserna. Mer information finns i Quickstart: Konfigurera en Azure virtuell dator för att ansluta till Azure SQL Managed Instance.

Om din SQL Server på Azure Virtual Machines instans finns i ett annat virtuellt nätverk än din SQL-hanterade instans måste du ansluta de två virtuella nätverken. Virtuella nätverk behöver inte finnas i samma prenumeration för att det här scenariot ska fungera.

Det finns två alternativ för att ansluta virtuella nätverk:

Peering är att föredra eftersom det använder Microsoft stamnätverk. Så ur ett anslutningsperspektiv finns det ingen märkbar skillnad i svarstid mellan virtuella datorer i ett peer-kopplat virtuellt nätverk och i samma virtuella nätverk. Peering för virtuella nätverk stöds mellan nätverk i samma region. Global virtuell nätverkskoppling stöds för instanser som finns i undernät som skapats efter den 22 september 2020. Mer information finns i Vanliga frågor och svar.

SQL Server utanför Azure

Om din SQL Server instans finns utanför Azure upprättar du en VPN-anslutning mellan SQL Server och SQL Managed Instance med något av följande alternativ:

Tips/Råd

Vi rekommenderar ExpressRoute för bästa nätverksprestanda när du replikerar data. Etablera en gateway med tillräckligt med bandbredd för ditt användningsfall.

Nätverksportar mellan miljöer

Oavsett anslutningsmekanismen finns det krav som måste uppfyllas för att nätverkstrafiken ska kunna flöda mellan miljöerna:

NSG-reglerna (Network Security Group) på undernätet som är värd för SQL Managed Instance måste tillåta:

  • Inkommande port 5022 och portintervall 11000-11999 för att ta emot trafik från källan SQL Server IP
  • Utgående port 5022 för att skicka trafik till målet SQL Server IP

Alla brandväggar i nätverket som är värd för SQL Server och värdoperativsystemet måste tillåta:

  • Inkommande port 5022 öppnades för att ta emot trafik från källans IP-intervall för MI-undernätet /24 (till exempel 10.0.0.0/24)
  • Utgående portar 5022 och portintervallet 11000-11999 öppnades för att skicka trafik till mål-IP-intervallet för MI-undernätet (exempel 10.0.0.0/24)

Diagram som visar nätverkskrav för att konfigurera länken mellan SQL Server och SQL Managed Instance.

I följande tabell beskrivs portåtgärder för varje miljö:

Miljö Lämplig åtgärd
SQL Server (i Azure) Öppna både inkommande och utgående trafik på port 5022 för nätverksbrandväggen till hela undernätets IP-intervall för SQL Managed Instance. Om det behövs gör du samma sak i brandväggen för SQL Server värdoperativsystem (Windows/Linux). Om du vill tillåta kommunikation på port 5022 skapar du en nätverkssäkerhetsgruppsregel (NSG) i det virtuella nätverk som är värd för den virtuella datorn (VM).
SQL Server (utanför Azure) Öppna både inkommande och utgående trafik på port 5022 för nätverksbrandväggen till hela undernätets IP-intervall för SQL Managed Instance. Om det behövs gör du samma sak i brandväggen för SQL Server värdoperativsystem (Windows/Linux).
SQL Managed Instance Skapa en NSG-regel i Azure portalen för att tillåta inkommande och utgående trafik från IP-adressen och nätverken som är värdar för SQL Server på port 5022 och portintervallet 11000-11999.

Om du vill öppna portar i Windows-brandväggen använder du följande PowerShell-skript på Windows värdoperativsystemet för SQL Server-instansen:

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

Följande diagram visar ett exempel på en lokal nätverksmiljö som anger att alla brandväggar i miljön måste ha öppna portar, inklusive operativsystembrandväggen som är värd för SQL Server och eventuella företagsbrandväggar och/eller gatewayer:

Diagram som visar nätverksinfrastrukturen för att konfigurera länken mellan SQL Server och SQL Managed Instance.

Viktigt!

  • Portar måste vara öppna i varje brandvägg i nätverksmiljön, inklusive värdservern och eventuella företagsbrandväggar eller gatewayer i nätverket. I företagsmiljöer kan du behöva visa nätverksadministratören informationen i det här avsnittet för att öppna ytterligare portar i företagsnätverksskiktet.
  • Du kan välja att anpassa slutpunkten på SQL Server sidan, men portnummer för SQL Managed Instance kan inte ändras eller anpassas.
  • IP-adressintervall för undernät som är värdar för hanterade instanser och SQL Server får inte överlappa varandra.

Lägg till URL:er i listan över tillåtna

Beroende på nätverkssäkerhetsinställningarna kan det vara nödvändigt att lägga till URL:er i listan över tillåtna för SQL Managed Instance FQDN och några av de resurshanteringsslutpunkter som används av Azure.

Följande visar de resurser som ska läggas till i listan över tillåtna:

  • Det fullständigt kvalificerade domännamnet (FQDN) för din SQL Managed Instance. Till exempel: managedinstance.a1b2c3d4e5f6.database.windows.net.
  • Microsoft Entra Myndighet
  • Microsoft Entra Resurs-ID för slutpunkt
  • Resource Manager slutpunkt
  • Tjänstslutpunkt

Följ stegen i avsnittet Konfigurera SSMS för myndighetsmoln för att få åtkomst till gränssnittet Tools i SQL Server Management Studio (SSMS) och identifiera specifika URL:er för de resurser i molnet som du behöver lägga till i listan över tillåtna.

Testa nätverksanslutning

Dubbelriktad nätverksanslutning mellan SQL Server och SQL Managed Instance krävs för att länken ska fungera. När du har öppnat portar på SQL Server sidan och konfigurerat en NSG-regel på SQL Managed Instance sidan testar du anslutningen med antingen SQL Server Management Studio (SSMS) eller Transact-SQL.

Testa nätverket genom att skapa ett tillfälligt SQL Agent-jobb på både SQL Server och SQL Managed Instance för att kontrollera anslutningen mellan de två instanserna. När du använder Network Checker i SSMS skapas jobbet automatiskt åt dig och tas bort när testet har slutförts. Du måste ta bort SQL Agent-jobbet manuellt om du testar nätverket med hjälp av T-SQL.

Anmärkning

Det går inte att köra PowerShell-skript av SQL Server Agent på SQL Server on Linux för närvarande, så det går för närvarande inte att köra Test-NetConnection från SQL Server Agent-jobbet på SQL Server on Linux.

Om du vill använda SQL-agenten för att testa nätverksanslutningen behöver du följande krav:

  • Användaren som utför testet måste ha behörigheter för att skapa ett jobb (antingen som en sysadmin eller tillhör rollen SQLAgentOperator för msdb) för både SQL Server och SQL Managed Instance.
  • Tjänsten SQL Server Agent måste vara running på SQL Server. Eftersom agenten är aktiverad som standard på SQL Managed Instance krävs ingen ytterligare åtgärd.

Tänk på följande:

  • För att undvika falska negativa resultat måste alla brandväggar i nätverket tillåta ICMP-trafik (Internet Control Message Protocol).
  • För att undvika falska positiva resultat måste alla brandväggar längs nätverkets väg tillåta trafik på det proprietära SQL Server UCS-protokollet. Blockering av protokollet kan leda till ett lyckat anslutningstest, men länken kan inte skapas.
  • Avancerade brandväggsinstallationer med skyddsräcken på paketnivå måste konfigureras korrekt för att tillåta trafik mellan SQL Server och SQL Managed Instance.

Följ dessa steg för att testa nätverksanslutningen mellan SQL Server och SQL Managed Instance i SSMS:

  1. Anslut till den instans som ska fungera som den primära repliken i SSMS.

  2. I Object Explorer expanderar du databaser och högerklickar på den databas som du vill länka till den sekundära. Välj Tasks>Azure SQL Managed Instance link>Test Connection för att öppna Network Checker guiden:

    Skärmbild av objektutforskaren i SSMS med testanslutningen markerad i snabbmenyn för databaslänken.

  3. Välj Nästa på sidan Introduktion i guiden Nätverkskontroll .

  4. Om alla krav uppfylls på sidan Förutsättningar väljer du Nästa. Lös annars eventuella ouppfyllda krav och välj sedan Kör validering igen.

  5. På sidan Inloggning väljer du Logga in för att ansluta till den andra instansen som ska vara den sekundära repliken. Välj Nästa.

  6. Kontrollera informationen på sidan Ange nätverksalternativ och ange en IP-adress om det behövs. Välj Nästa.

  7. På sidan Sammanfattning granskar du de åtgärder som guiden vidtar och väljer sedan Slutför för att testa anslutningen mellan de två replikerna.

  8. Granska sidan Resultat för att verifiera att anslutningen finns mellan de två replikerna och välj sedan Stäng för att slutföra.

Försiktighet

Fortsätt endast med nästa steg om du har verifierat nätverksanslutningen mellan käll- och målmiljöerna. Annars kan du felsöka problem med nätverksanslutningen innan du fortsätter.

Migrera ett certifikat för en TDE-skyddad databas (valfritt)

Om du länkar en SQL Server databas som skyddas av Transparent Data Encryption (TDE) till en SQL-hanterad instans måste du migrera motsvarande krypteringscertifikat från den lokala eller Azure virtuella datorn SQL Server instans till den SQL-hanterade instansen innan du använder länken. Detaljerade steg finns i Migrera ett certifikat för en TDE-skyddad databas till Azure SQL Managed Instance.

SQL Managed Instance databaser som krypteras med tjänsthanterade TDE-nycklar kan inte länkas till SQL Server. Du kan bara länka en krypterad databas till SQL Server om den krypterades med en kundhanterad nyckel och målservern har åtkomst till samma nyckel som används för att kryptera databasen. Mer information finns i Set up SQL Server TDE with Azure Key Vault.

Anmärkning

Azure Key Vault stöds av SQL Server on Linux från och med Cumulative Update 14 för SQL Server 2022.

Installera SSMS

SQL Server Management Studio (SSMS) är det enklaste sättet att använda länken Managed Instance. Installera den senaste versionen av SQL Server Management Studio (SSMS) på klientdatorn.

När installationen är klar öppnar du SSMS och ansluter till den SQL Server instans som stöds. Högerklicka på en användardatabas och kontrollera att alternativet Azure SQL Managed Instance visas på menyn.

Screenshot som visar alternativet Azure SQL Managed Instance länk på snabbmenyn.

Konfigurera SSMS för myndighetsmoln

Om du vill distribuera din SQL Managed Instance till ett myndighetsmoln måste du ändra inställningarna för SQL Server Management Studio (SSMS) för att använda rätt moln. Om du inte distribuerar din SQL Managed Instance till ett myndighetsmoln hoppar du över det här steget.

Följ dessa steg för att uppdatera SSMS-inställningarna:

  1. Öppna SSMS.
  2. På menyn väljer du Verktyg och sedan Alternativ.
  3. Expandera Azure Services och välj Azure Cloud.
  4. Under Select an Azure Cloud använder du listrutan för att välja AzureUSGovernment eller ett annat myndighetsmoln, till exempel AzureChinaCloud:

Skärmbild av SSMS-användargränssnittet, alternativsidan, Azure tjänster med Azure moln markerat.

Om du vill gå tillbaka till det offentliga molnet väljer du AzureCloud i listrutan.

Så här använder du länken:

Om du vill veta mer om länken:

Överväg följande för andra replikerings- och migreringsscenarier: