Spostare Istanza gestita di SQL di Azure tra subnet

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo illustra come spostare l'istanza gestita di Azure SQL da una subnet a un'altra (nella stessa rete virtuale o in una diversa), in modo analogo al ridimensionamento dei vCore o alla modifica del livello di servizio dell'istanza. Istanza gestita di SQL è disponibile durante lo spostamento, ad eccezione di un breve tempo di inattività causato da un failover alla fine dell'aggiornamento, in genere fino a 10 secondi, anche se le transazioni a esecuzione prolungata vengono interrotte.

Lo spostamento dell'istanza in un'altra subnet attiva le seguenti operazioni del cluster virtuale:

• Il cluster virtuale creerà o ridimensionerà l'infrastruttura sottostante nella subnet di destinazione.
• Il cluster virtuale viene rimosso o deframmentato nella subnet di origine.

Requisiti e limitazioni

L'Istanza gestita di SQL deve essere distribuita all'interno di una subnet dedicata in una rete virtuale di Azure. Il numero di istanze gestite che possono essere distribuite nella subnet dipende dalle dimensioni della subnet (intervallo di subnet). Per distribuire un'istanza gestita o spostarla in un'altra subnet, la subnet di destinazione deve avere determinati requisiti di rete.

Prima di spostare l'istanza in un'altra subnet, è consigliabile acquisire familiarità con i concetti seguenti:

• Determinare le dimensioni e l'intervallo della subnet richiesta per Istanza gestita di SQL di Azure.
• Scegliere tra lo spostamento dell'istanza in una nuova subnet o l'uso di una subnet esistente.
• Eseguire operazioni di gestione per distribuire automaticamente nuove istanze gestite, aggiornare le proprietà di un'istanza ed eliminare le istanze. È possibile monitorare queste operazioni di gestione.

Idoneità della subnet

Prima di spostare l'istanza gestita, verificare che la subnet sia contrassegnata come Pronta per l'istanza gestita.

Nell'interfaccia utente della rete virtuale del portale di Azure, ogni rete virtuale che soddisfi i prerequisiti per un'istanza gestita viene classificata come Pronta per l'istanza gestita. Le reti virtuali con subnet con istanze gestite già distribuite visualizzano un'icona Istanza gestita di SQL prima del nome della rete virtuale. Le subnet vuote pronte per un'istanza gestita visualizzano l'icona Subnet di rete virtuale.

Le subnet contrassegnate come Non pronte non soddisfano tutti i requisiti per la distribuzione di Istanza gestita di SQL. Usare l'icona delle informazioni a destra del nome della subnet per scoprire perché la subnet non è pronta e se può soddisfare i requisiti di rete. I requisiti includono:

• delega al provider di risorse Microsoft.Sql/managedInstances
• collegamento di una tabella di routing
• collegamento di un gruppo di sicurezza di rete

Nel caso in cui la subnet faccia parte di un'altra rete virtuale, sono previsti requisiti aggiuntivi:

• Peering bidirezionale tra la rete virtuale corrente e quella di destinazione.
• Le subnet correnti e di destinazione usano tabelle di routing separate e gruppi di sicurezza di rete.

Dopo aver soddisfatto tutti i requisiti, la subnet passa dalla categoria Non pronte a Pronta per l'istanza gestita e può essere usata per un'istanza gestita.

La subnet già in uso (le subnet usate per le distribuzioni di istanze non possono contenere altre risorse) o la subnet ha una zona DNS diversa (una limitazione di spostamento tra istanze della subnet) fa sempre parte della categoria Non pronte.

A seconda dello stato e della designazione della subnet, è possibile apportare le modifiche seguenti alla subnet di destinazione:

• Pronta per l'istanza gestita (contiene l'istanza gestita di SQL esistente): non vengono apportate modifiche. Queste subnet contengono già istanze gestite e apportare qualsiasi modifica alla subnet potrebbero influire sulle istanze esistenti.
• Pronta per l'istanza gestita (vuota): il flusso di lavoro convalida tutte le regole necessarie nel gruppo di sicurezza di rete e nella tabella di routing e aggiunge tutte le regole necessarie ma mancanti. ¹

Nota

¹ Le regole personalizzate aggiunte alla configurazione della subnet di origine non vengono copiate nella subnet di destinazione. Qualsiasi personalizzazione della configurazione della subnet di origine deve essere replicata manualmente nella subnet di destinazione. Un modo per ottenere questo risultato consiste nell'usare la stessa tabella di route e lo stesso gruppo di sicurezza di rete per la subnet di origine e quella di destinazione.

Limitazioni della subnet di destinazione

Quando si sceglie una subnet di destinazione per un'istanza esistente, prendere in considerazione le limitazioni seguenti:

• Istanza gestita di SQL può essere spostata nella subnet:

  • Nella stessa rete virtuale attualmente usata,
  • In una rete virtuale con peering, se si passa a una subnet in un'altra rete virtuale.

• La zona DNS delle istanze nella subnet di destinazione deve corrispondere alla zona DNS dell'istanza da spostare. Questa limitazione si applica se si prevede di passare a una subnet non vuota.

  • È possibile preparare appositamente la subnet di destinazione per mantenere la zona DNS dell'Istanza gestita di SQL spostata. La preparazione può essere eseguita creando una nuova Istanza gestita di SQL in una subnet vuota e fornendo il parametro dnsZonePartner nella richiesta di creazione. Questo parametro come valore accetta l'ID di Istanza gestita di SQL e, in questo caso, è possibile usare l'istanza che verrà successivamente spostata nella nuova subnet¹.

Nota

¹ Al di là di questo approccio non esiste un altro modo per determinare la zona DNS di Istanza gestita di SQL poiché viene generata in modo casuale. Attualmente, inoltre, non esiste un modo per aggiornare la zona DNS di un'Istanza gestita di SQL esistente.

• Se si vuole eseguire la migrazione di un'Istanza gestita di SQL con un gruppo di failover, si applicano i prerequisiti seguenti:
  • La subnet di destinazione deve avere le stesse regole di sicurezza necessarie per la replica del gruppo di failover della subnet di origine: Aprire le porte 5022 in entrata e in uscita e l'intervallo 11000~11999 nel Network Security Group (NSG) per le connessioni dall'altra subnet dell'istanza gestita (quella che contiene la replica del gruppo di failover) per consentire il traffico di replica tra le due istanze.
  • La subnet di destinazione non può avere un intervallo di indirizzi sovrapposto con la subnet che contiene la replica dell'istanza secondaria del gruppo di failover. Ad esempio, se MI1 si trova nella subnet S1, l'istanza secondaria nel gruppo di failover è MI2 nella subnet S2. Si vuole spostare MI1 nella subnet S3. La subnet S3 non può avere un intervallo di indirizzi sovrapposto con la subnet S2.

Per altre informazioni sulla configurazione della rete per i gruppi di failover, vedere Abilitare la replica geografica tra istanze gestite.

Passaggi dell'operazione

Lo spostamento di un'istanza da una subnet a un'altra comporta diversi passaggi e, a seconda della configurazione del Istanza gestita di SQL, può richiedere da 30 minuti a 6 ore.

La seguente tabella descrive in dettaglio i passaggi da seguire durante l'operazione di spostamento dell'istanza:

Nome passaggio	Descrizione passaggio
Convalida delle richieste	Convalida dei parametri inviati. Se viene rilevata una configurazione errata, l'operazione non riesce e appare un errore.
Ridimensionamento/creazione del cluster virtuale	A seconda dello stato della subnet di destinazione, il cluster virtuale viene creato o ridimensionato.
Avvio di una nuova istanza	Il processo SQL viene avviato nel cluster virtuale distribuito nella subnet di destinazione.
Seeding/collegamento dei file di database	A seconda del livello di servizio, il database viene sottoposto a seeding o i file di database vengono collegati.
Preparazione ed esecuzione del failover	Dopo il seeding dei dati e una volta ricollegati i file di database, il sistema viene preparato per il failover. Quando tutto è pronto, il sistema esegue un failover con un breve tempo di inattività, in genere inferiore a 10 secondi.
Pulizia delle istanze di SQL	Rimuove il processo SQL precedente dal cluster virtuale di origine.
Eliminazione del cluster virtuale	Se si tratta dell'ultima istanza all'interno della subnet di origine, il passaggio finale elimina il cluster virtuale in modo sincrono. In caso contrario, il cluster virtuale viene deframmentato in modo asincrono.

Una spiegazione dettagliata dei passaggi dell'operazione è disponibile nella panoramica delle operazioni di gestione di Istanza gestita di SQL di Azure

Spostare l'istanza

Lo spostamento di un'istanza tra subnet fa parte dell'operazione di aggiornamento dell'istanza. L'API di aggiornamento dell'istanza esistente, Azure PowerShell e i comandi dell'interfaccia della riga di comando di Azure sono stati migliorati con una proprietà ID della subnet.

Nel portale di Azure usare il campo Subnet nel riquadro di Rete per spostare l'istanza nella subnet di destinazione. Quando si usa Azure PowerShell o l'interfaccia della riga di comando di Azure, specificare un ID subnet diverso nel comando di aggiornamento per spostare l'istanza da una subnet esistente alla subnet di destinazione.

Per un riferimento completo ai comandi di gestione delle istanze, vedere Riferimento sulle API di gestione per Istanza gestita di SQL di Azure.

Portale

L'opzione per scegliere la subnet dell'istanza si trova nel riquadro Rete del portale di Azure. L'operazione di spostamento dell'istanza viene avviata quando si seleziona una subnet e si salvano le modifiche.

Il primo passaggio dell'operazione di spostamento consiste nel preparare la subnet di destinazione per la distribuzione, il che può richiedere alcuni minuti. Quando la subnet è pronta, viene avviata l'operazione di gestione dello spostamento dell'istanza, che diventa visibile nel portale di Azure.

Monitorare le operazioni di spostamento delle istanze dal riquadro Panoramica del portale di Azure. Selezionare la notifica per aprire un riquadro aggiuntivo contenente informazioni sul passaggio corrente, il totale dei passaggi e un pulsante per annullare l'operazione.

PowerShell

Usare il comando di Azure PowerShell Set-AzSqlInstance per spostare un'istanza dopo aver creato la subnet nella stessa rete virtuale della subnet di destinazione. Se si vuole usare una subnet esistente, specificare il nome della subnet nel comando di PowerShell.

I comandi di PowerShell di esempio in questa sezione preparano la subnet di destinazione per la distribuzione dell'istanza e spostano l'istanza gestita.

Usare il comando di PowerShell seguente specificando i parametri:

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

Ignorare questo comando se nella subnet sono già state distribuite istanze. Se si usa una nuova subnet, usare il comando di Azure PowerShell seguente per preparare la subnet:

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

Nota

Per altre informazioni sullo script che prepara la subnet, vedere Configurare una rete virtuale esistente per Istanza gestita di SQL di Azure.

Il comando di Azure PowerShell seguente sposta l'istanza nella subnet di origine:

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

Il comando di Azure PowerShell seguente sposta l'istanza e offre anche un modo per monitorare lo stato di avanzamento:

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

Interfaccia della riga di comando di Azure

Usare il comando di Azure della CLI az sql mi update per spostare l'istanza in un'altra subnet.

Specificare la destinazione specificando l'ID subnet come proprietà --subnet oppure specificando il nome della rete virtuale come proprietà --vnet-name e il nome della subnet come proprietà --subnet.

L'esempio seguente sposta l'istanza gestita in un'altra subnet specificando l'ID subnet:

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

L'esempio seguente sposta l'istanza gestita in un'altra subnet specificando il nome della rete virtuale e il nome della subnet:

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

Usare il comando seguente per monitorare lo stato di avanzamento dell'operazione di gestione:

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

Passaggi successivi

• Per informazioni su come creare la prima istanza gestita, vedere Guida di avvio rapido.
• Per un elenco di funzionalità e di confronto, vedere Funzionalità comuni di SQL.
• Per altre informazioni sulla configurazione della rete virtuale, vedere Configurazione di una rete virtuale per Istanza gestita di SQL.
• Per una guida di avvio rapido sulla creazione di un'istanza gestita e il ripristino di un database da un file di backup, vedere Creare un'istanza gestita.
• Per un'esercitazione sull'uso del Servizio Migrazione del database di Azure, vedere Migrazione a Istanza gestita di SQL con il Servizio Migrazione del database.