Spostare Istanza gestita di SQL di Azure tra subnet

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo illustra come spostare Istanza gestita di SQL di Azure da una subnet a un'altra nella stessa rete virtuale o in una rete virtuale diversa. L'operazione è simile al ridimensionamento di vCore o alla modifica del livello di servizio dell'istanza. Durante lo spostamento, Istanza gestita di SQL rimane disponibile, ad eccezione di un breve tempo di inattività quando si verifica il failover, in genere dura 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 compila o ridimensiona l'infrastruttura sottostante nella subnet di destinazione.
• Il cluster virtuale viene rimosso o deframmentato nella subnet di origine.

Requisiti e limitazioni

È necessario distribuire Istanza gestita di SQL all'interno di una subnet dedicata all'interno di una rete virtuale di Azure. Le dimensioni della subnet (intervallo di subnet) determinano il numero di istanze gestite di SQL che è possibile distribuire all'interno della subnet. Per distribuire un'istanza gestita di SQL o spostarla in un'altra subnet, la subnet di destinazione deve soddisfare 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 di SQL, verificare che la subnet sia contrassegnata come Pronto per Istanza gestita.

Nell'interfaccia utente della rete virtuale del portale di Azure le reti virtuali che soddisfano i prerequisiti per un'istanza gestita di SQL vengono classificate come Ready for Managed Instance. Le reti virtuali con subnet con istanze gestite di SQL già distribuite visualizzano un'icona di Istanza gestita di SQL prima del nome della rete virtuale. Le subnet vuote pronte per un'istanza gestita di SQL visualizzano un'icona di subnet di rete virtuale.

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

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

Se la subnet fa parte di un'altra rete virtuale, è necessario:

• 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 questi requisiti, la subnet passa dalla categoria Non pronto a Istanza gestita e può essere usata per un'istanza gestita di SQL.

Le subnet già in uso (le subnet usate per le distribuzioni di istanze non possono contenere altre risorse) o le subnet con una zona DNS diversa (una limitazione di spostamento tra istanze di subnet) fanno sempre parte della categoria Non pronto .

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

• Pronto per Istanza gestita (contiene Istanza gestita di SQL esistente)

  Non vengono apportate rettifiche. Queste subnet contengono già istanze gestite di SQL e possono influire sulle istanze esistenti.

• Pronto per Istanza gestita (vuoto)

  Il flusso di lavoro convalida tutte le regole necessarie nel gruppo di sicurezza di rete e nella tabella di route e aggiunge tutte le regole necessarie ma mancanti. Le regole personalizzate aggiunte alla configurazione della subnet di origine non vengono copiate nella subnet di destinazione. È necessario replicare manualmente qualsiasi personalizzazione della configurazione della subnet di origine nella subnet di destinazione. Un modo per ottenere questa replica consiste nell'usare la stessa tabella di route e lo stesso gruppo di sicurezza di rete per la subnet di origine e di destinazione.

Limitazioni della subnet di destinazione

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

• È possibile spostare Istanza gestita di SQL in una subnet che sia:

  • Nella stessa rete virtuale di quella attualmente usata o
  • 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 valida.

  È possibile preparare appositamente la subnet di destinazione per conservare la zona DNS dell'istanza gestita di SQL che si sta spostando. Preparare la subnet creando una nuova istanza gestita di SQL in una subnet vuota e fornendo il dnsZonePartner parametro 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.

  Oltre a questo approccio, non esiste un altro modo per determinare la zona DNS dell'istanza gestita di SQL perché viene generata in modo casuale. Attualmente, non è possibile 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 sia le porte in ingresso che in uscita 5022 e l'intervallo 11000-11999 nel gruppo di sicurezza di rete (NSG) per le connessioni dall'altra subnet dell'istanza gestita di SQL (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 di SQL.

Passaggi dell'operazione

Lo spostamento di un'istanza da una subnet a un'altra comporta molti passaggi. A seconda della configurazione dell'istanza gestita di SQL, l'operazione di spostamento 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 o creazione di cluster virtuali	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.
Avvio di file di database o collegamento di 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 o la riattaccamento dei file di database, il sistema si prepara 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.

Per una spiegazione dettagliata dei passaggi dell'operazione, vedere Durata delle operazioni di gestione in 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, i comandi di Azure PowerShell e dell'interfaccia della riga di comando di Azure vengono migliorati con una proprietà ID 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 il Riferimento delle API gestite per Istanza gestita di Azure SQL.

Portale

È possibile scegliere la subnet dell'istanza nel riquadro Rete del portale di Azure. Dopo aver selezionato una subnet e aver salvato le modifiche, viene avviata l'operazione di spostamento dell'istanza.

L'operazione di spostamento prepara prima la subnet di destinazione per la distribuzione, che può richiedere alcuni minuti. Dopo che la subnet è pronta, l'operazione di gestione dello spostamento dell'istanza viene avviata e visualizzata nel portale di Azure.

È possibile monitorare le operazioni di spostamento delle istanze dal riquadro Panoramica del portale di Azure. Selezionare la notifica per aprire un altro riquadro contenente informazioni sul passaggio corrente, i passaggi totali 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. Per 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 di SQL.

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 preparation script
Invoke-Command -ScriptBlock ([Scriptblock]::Create((Invoke-WebRequest ($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 di SQL 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 di SQL 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

Contenuti correlati

• Avvio rapido: Creare un'istanza gestita di SQL di Azure
• Confronto delle funzionalità: Database SQL di Azure e Istanza gestita di SQL di Azure
• Architettura della connettività per Istanza gestita di SQL di Azure
• Migrazione di Istanza gestita di SQL con Servizio Migrazione del database