Flytta Azure SQL Managed Instance mellan undernät

Artikel
07/31/2023

Gäller för:Azure SQL Managed Instance

Azure SQL Managed Instance måste distribueras i ett dedikerat undernät i ett virtuellt Azure-nätverk. Antalet hanterade instanser som kan distribueras i undernätet beror på storleken på undernätet (undernätsintervallet).

I den här artikeln lär du dig att flytta din hanterade instans från ett undernät till ett annat (i samma virtuella nätverk eller ett annat), som att skala virtuella kärnor eller ändra instanstjänstnivån. SQL Managed Instance är tillgängligt under flytten, förutom under en kort stilleståndstid som orsakas av en redundansväxling i slutet av uppdateringen , som 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.

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.

Krav och begränsningar

Om du vill distribuera en hanterad instans eller flytta den till ett annat undernät måste målundernätet ha vissa nätverkskrav.

Beredskap för undernät

Innan du flyttar den hanterade instansen 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 hanterad instans som Redo för hanterad instans. Virtuella nätverk som har undernät med 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 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 har uppfyllts flyttas undernätet från kategorin Inte redo till kategorin Klar för hanterad instans och kan användas för en hanterad instans.

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

Screenshot of the Azure SQL Managed Instance subnet options.

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 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. ¹

Kommentar

¹ 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 flyttar 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-tomt undernät.
- Du kan särskilt förbereda målundernätet för att behålla DNS-zonen för SQL Managed Instance 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:t 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¹.

Kommentar

¹ 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 undernätet för hanterad instans (den som innehåller redundansklusterrepliken) 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 hanterade instanser.

Åtgärdssteg

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

Stegnamn	Stegbeskrivning
Begäran om validering	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.
Start av ny instans	SQL-processen startar på det distribuerade virtuella klustret i målundernätet.
Seeding database files/attaching database files	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 på nytt förbereder systemet för redundansväxling. När allt är klart utför systemet en redundansväxling med kort stilleståndstid, vanligtvis 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 översikten ö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 har förbättrats med en undernäts-ID-egenskap.

I Azure-portalen använder du undernätsfältet på bladet 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 att välja instansundernätet finns på bladet 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.

How to select subnet on SQL Managed Instance networking blade

Övervaka flyttåtgärder för instanser från bladet Översikt i Azure-portalen. Välj meddelandet för att öppna ett ytterligare blad 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 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 distribuerat instanser till 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 prepartion script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Kommentar

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 instansen till ett annat undernät genom att ange undernäts-ID:t:

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 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

Nästa steg

Mer information om hur du skapar din första hanterade instans finns i snabbstartsguiden.
En funktions- och jämförelselista finns i vanliga SQL-funktioner.
Mer information om VNet-konfiguration finns i SQL Managed Instance VNet-konfiguration.
En snabbstart som skapar en hanterad instans och återställer en databas från en säkerhetskopia finns i Skapa en hanterad instans.
En självstudiekurs om hur du använder Azure Database Migration Service för migrering finns i SQL Managed Instance-migrering med Hjälp av Database Migration Service.

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

Nästa steg

Feedback

Ytterligare resurser