Flytta Azure SQL Managed Instance mellan undernät

2025-08-28

gäller för:Azure SQL Managed Instance

Den här artikeln beskriver hur du flyttar Azure SQL Managed Instance från ett undernät till ett annat i samma virtuella nätverk eller ett annat. Åtgärden liknar skalning av virtuella kärnor eller ändring av instanstjänstnivån. Under flytten förblir SQL Managed Instance tillgängligt, förutom en kort stilleståndstid när redundansväxlingen sker – vanligtvis varar upp till 10 sekunder, även om långvariga transaktioner avbryts.

Om du flyttar instansen till ett annat undernät utlöses följande åtgärder för virtuella kluster:

Det virtuella klustret skapar eller ändrar storlek på den underliggande infrastrukturen i målundernätet.
Det virtuella klustret tas bort eller defragmenteras i källundernätet.

Krav och begränsningar

SQL Managed Instance måste distribueras i ett dedikerat undernät i ett virtuellt Azure-nätverk. Antalet SQL-hanterade instanser som kan distribueras i undernätet beror på storleken på undernätet (undernätsintervallet). Om du vill distribuera en SQL-hanterad instans eller flytta den till ett annat undernät måste målundernätet ha vissa nätverkskrav.

Innan du flyttar instansen till ett annat undernät bör du överväga att bekanta dig med följande begrepp:

Fastställa nödvändig storlek och intervall för undernätet för Azure SQL Managed Instance.
Välj mellan att flytta instansen till ett nytt undernät eller att använda ett befintligt undernät.
Använd hanteringsåtgärder för att automatiskt distribuera nya hanterade instanser, uppdatera instansegenskaper eller ta bort instanser. Det går att övervaka dessa hanteringsåtgärder.

Beredskap för undernät

Innan du flyttar din SQL-hanterade instans bekräftar du att undernätet har markerats som Redo för hanterad instans.

I användargränssnittet för virtuellt nätverk i Azure-portalen kategoriseras virtuella nätverk som uppfyller kraven för en SQL-hanterad instans som Redo för hanterad instans. Virtuella nätverk som har undernät med SQL-hanterade instanser som redan har distribuerats till dem visar en SQL Managed Instance-ikon före namnet på det virtuella nätverket. Tomma undernät som är redo för en SQL-hanterad instans visar en undernätsikon för virtuellt nätverk.

Undernät som är markerade som Inte redo uppfyller inte alla krav för SQL Managed Instance-distribution. Använd informationsikonen till höger om undernätets namn för att lära dig varför undernätet inte är klart och om undernätet kan uppfylla nätverkskraven. Dessa krav omfattar:

delegera till resursprovidern Microsoft.Sql/managedInstances
bifoga en routningstabell
ansluta en nätverkssäkerhetsgrupp

Om undernätet ingår i något annat virtuellt nätverk är extra krav:

Dubbelriktad peering mellan aktuellt och mål virtuellt nätverk.
Aktuella undernät och målundernät använder separata routningstabeller och nätverkssäkerhetsgrupper.

När alla krav är uppfyllda flyttas undernätet från kategorin Inte redo till kategorin Klar för hanterad instans och kan användas för en SQL-hanterad instans.

Undernät som redan används (undernät som används för instansdistributioner kan inte innehålla andra resurser) eller undernät som har en annan DNS-zon (en flyttbegränsning mellan undernät) är alltid en del av kategorin Inte redo .

Skärmbild av undernätsalternativen för Azure SQL Managed Instance.

Beroende på undernätets tillstånd och beteckning kan följande justeringar göras i målundernätet:

Klar för hanterad instans (innehåller befintlig SQL Managed Instance): Inga justeringar görs. Dessa undernät innehåller redan SQL-hanterade instanser, och om du gör ändringar i undernätet kan det påverka befintliga instanser.
Klar för Hanterad instans (tom): Arbetsflödet verifierar alla nödvändiga regler i nätverkssäkerhetsgruppen och routningstabellen och lägger till eventuella regler som är nödvändiga men som saknas. ¹

Anmärkning

¹ Anpassade regler som läggs till i källundernätskonfigurationen kopieras inte till målundernätet. Du måste manuellt replikera alla anpassningar av källundernätskonfigurationen till målundernätet. Ett sätt du kan uppnå detta på är att använda samma routningstabell och nätverkssäkerhetsgrupp för käll- och målundernätet.

Målundernätsbegränsningar

Tänk på följande begränsningar när du väljer ett målundernät för en befintlig instans:

SQL Managed Instance kan flyttas till det undernät som antingen är:
- I samma virtuella nätverk som för närvarande används,
- I ett peer-kopplat virtuellt nätverk, om du skulle flytta till ett undernät i ett annat virtuellt nätverk.
DNS-zonen för instanserna i målundernätet måste matcha DNS-zonen för den instans som flyttas. Den här begränsningen gäller om du planerar att flytta till ett icke-undernät.
- Du kan särskilt förbereda målundernätet för att behålla DNS-zonen för den SQL-hanterade instans som flyttas. Du kan förbereda genom att skapa en ny SQL Managed Instance i ett tomt undernät och ange parametern dnsZonePartner i create-begäran. Den här parametern som ett värde accepterar ID för SQL Managed Instance, och i det här fallet kan du använda den instans som senare skulle flyttas till det nya undernätet¹.

Anmärkning

¹ Förutom den här metoden finns det inget annat sätt för dig att diktera DNS-zonen för SQL Managed Instance eftersom den genereras slumpmässigt. Det finns inte heller något sätt att uppdatera DNS-zonen för en befintlig SQL Managed Instance från och med nu.

Om du vill migrera en SQL Managed Instance med en redundansgrupp gäller följande krav:

Målundernätet måste ha samma säkerhetsregler som krävs för replikering av redundansklustergrupper som källundernätet:
- Öppna både inkommande och utgående portar 5022 och intervallet 11000~11999 i nätverkssäkerhetsgruppen (NSG) för anslutningar från det andra SQL-hanterade instansundernätet (det som innehåller repliken för redundansgrupper) för att tillåta replikeringstrafik mellan de två instanserna.
Målundernätet kan inte ha ett överlappande adressintervall med det undernät som innehåller den sekundära instansrepliken av redundansgruppen.
- Om MI1 till exempel finns i undernät S1 är den sekundära instansen i redundansgruppen MI2 i undernätet S2. Vi vill flytta MI1 till undernät S3. Undernät S3 kan inte ha ett överlappande adressintervall med undernät S2.

Mer information om hur du konfigurerar nätverket för redundansgrupper finns i Aktivera geo-replikering mellan SQL-hanterade instanser.

Åtgärdssteg

Att flytta en instans från ett undernät till ett annat innebär många steg, och beroende på hur din SQL Managed Instance har konfigurerats kan det ta allt från 30 minuter till 6 timmar.

I följande tabell beskrivs de åtgärdssteg som inträffar under instansflytten:

Stegnamn	Stegbeskrivning
Validering av begäran	Verifierar de inskickade parametrarna. Om en felkonfiguration identifieras misslyckas åtgärden med ett fel.
Storleksändring/skapande av virtuellt kluster	Beroende på målundernätets tillstånd skapas eller ändras det virtuella klustret.
Uppstart av ny instans	SQL-processen startar på det distribuerade virtuella klustret i målundernätet.
Initiera databashantering / bifoga databashanteringsfiler	Beroende på tjänstnivån är databasen antingen seedad eller så kopplas databasfilerna.
Förbereda redundans och redundans	När data har hämtats eller databasfilerna har kopplats om förbereder systemet för redundans. När allt är klart utför systemet en redundansväxling med kort stilleståndstid, vilket vanligtvis är mindre än 10 sekunder.
Gammal rensning av SQL-instans	Tar bort den gamla SQL-processen från det virtuella källklustret.
Borttagning av virtuellt kluster	Om det är den sista instansen i källundernätet tar det sista steget bort det virtuella klustret synkront. Annars defragmenteras det virtuella klustret asynkront.

En detaljerad förklaring av åtgärdsstegen finns i Översikt över hanteringsåtgärder för Azure SQL Managed Instance.

Flytta instansen

En flytt mellan undernätsinstanser är en del av instansuppdateringsåtgärden. Befintliga instansuppdaterings-API,Azure PowerShell- och Azure CLI-kommandon utökas med en undernäts-ID-egenskap.

I Azure-portalen använder du undernätsfältet i fönstret Nätverk för att flytta instansen till målundernätet. När du använder Azure PowerShell eller Azure CLI anger du ett annat undernäts-ID i uppdateringskommandot för att flytta instansen från ett befintligt undernät till målundernätet.

En fullständig referens för instanshanteringskommandon finns i Hanterings-API-referens för Azure SQL Managed Instance.

Alternativet för att välja instansundernätet finns i fönstret Nätverk i Azure-portalen. Instansflytten startar när du väljer ett undernät och sparar ändringarna.

Det första steget i flyttåtgärden är att förbereda målundernätet för distribution, vilket kan ta flera minuter. När undernätet är klart startar instansens flytthanteringsåtgärd och blir synlig i Azure-portalen.

Så här väljer du undernät i nätverksfönstret för SQL Managed Instance

Övervaka flyttåtgärder för instanser från fönstret Översikt i Azure-portalen. Välj meddelandet för att öppna ett annat fönster som innehåller information om det aktuella steget, totalt antal steg och en knapp för att avbryta åtgärden.

Använd Azure PowerShell-kommandot Set-AzSqlInstance för att flytta en instans när du har skapat ditt undernät i samma virtuella nätverk som målundernätet. Om du vill använda ett befintligt undernät anger du undernätets namn i PowerShell-kommandot.

PowerShell-exempelkommandona i det här avsnittet förbereder målundernätet för instansdistribution och flyttar den hanterade SQL-instansen.

Använd följande PowerShell-kommando för att ange dina parametrar:

### PART 1 - DEFINE PARAMETERS

#Generating basic parameters
$currentSubscriptionID = 'subscription-id'
$sqlMIResourceGroupName = 'resource-group-name-of-sql-mi'
$sqlMIName = 'sql-mi-name'
$sqlMIResourceVnetName = 'vnet-name-of-sql-mi'
$destinationSubnetName = 'name-of-the-destination-subnet-for-sql-mi'

Hoppa över det här kommandot om ditt undernät redan har instanser distribuerade i det. Om du använder ett nytt undernät använder du följande Azure PowerShell-kommando för att förbereda ditt undernät:

### PART 2 - PREPARE DESTINATION SUBNET

#Loading the url of script used for preparing the subnet for SQL MI deployment
$scriptUrlBase = 'https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/manage/azure-sql-db-managed-instance/delegate-subnet'

#Generating destination subnet parameters
$parameters = @{
    subscriptionId = $currentSubscriptionID
    resourceGroupName = $sqlMIResourceGroupName
    virtualNetworkName = $sqlMIResourceVnetName
    subnetName = $destinationSubnetName
}

#Initiating subnet preparation script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Anmärkning

Mer information om skriptet som förbereder undernätet finns i Konfigurera ett befintligt virtuellt nätverk för Azure SQL Managed Instance.

Följande Azure PowerShell-kommando flyttar instansen till källundernätet:

### PART 3 - MOVE INSTANCE TO THE NEW SUBNET

Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName"

Följande Azure PowerShell-kommando flyttar instansen och ger även ett sätt att övervaka förloppet:

### PART 3 EXTENDED - MOVE INSTANCE AND MONITOR PROGRESS

# Extend the Set-AzSqlInstance command with -AsJob -Force parameters to be able to monitor the progress or proceed with script execution as moving the instance to another subnet is long running operation
Set-AzSqlInstance -Name $sqlMIName -ResourceGroupName $sqlMIResourceGroupName `
-SubnetId "/subscriptions/$currentSubscriptionID/resourceGroups/$sqlMIResourceGroupName/providers/Microsoft.Network/virtualNetworks/$sqlMIResourceVnetName/subnets/$destinationSubnetName" -AsJob -Force

$operationProgress = Get-AzSqlInstanceOperation -ManagedInstanceName $sqlMIName -ResourceGroupName $sqlMIResourceGroupName
#checking the operation step status
Write-Host "Checking the ongoing step" -ForegroundColor Yellow
$operationProgress.OperationSteps.StepsList

Använd kommandot Azure CLI az sql mi update för att flytta instansen till ett annat undernät.

Ange målet genom att antingen ange undernäts-ID som --subnet egenskap eller genom att ange det virtuella nätverksnamnet som --vnet-name egenskapen och undernätets namn som --subnet egenskap.

I följande exempel flyttas den HANTERADE SQL-instansen till ett annat undernät genom att ange undernäts-ID:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --subnet /subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVirtualNetworkName/subnets/destinationSubnetName

I följande exempel flyttas den HANTERADE SQL-instansen till ett annat undernät genom att ange namnet på det virtuella nätverket och undernätets namn:

az sql mi update -g myResourceGroup -n mySqlManagedInstance --vnet-name myVirtualNetworkName --subnet destinationSubnetName

Använd följande kommando för att övervaka förloppet för hanteringsåtgärden:

az sql mi op list -g myResourceGroup --mi mySqlManagedInstance

Feedback

Var den här sidan till hjälp?

Dela via

Flytta Azure SQL Managed Instance mellan undernät

Krav och begränsningar

Beredskap för undernät

Målundernätsbegränsningar

Åtgärdssteg

Flytta instansen

Relaterat innehåll

Feedback

Ytterligare resurser