Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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, l'Istanza gestita di SQL rimane disponibile, ad eccezione di una breve interruzione del servizio quando si verifica il failover, che in genere dura fino a 10 secondi, anche se le transazioni di lunga durata 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.
Prima di avviare lo spostamento della subnet, verifica che sia consentita la connettività tra le subnet di origine e destinazione sulle porte 5022 e 11000-11999. Questa verifica include la convalida dell'intero percorso di rete e l'assicurazione che eventuali rotte definite dall'utente, appliance virtuali di rete (NVA), firewall o altri dispositivi di rete non stiano bloccando il traffico su queste porte.
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 Istanza gestita. Le reti virtuali che hanno subnet con istanze gestite di SQL già distribuite mostrano l'icona di Istanza gestita di SQL davanti al 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/managedInstancesfornitore di risorse - collegamento di una tabella di routing
- collegare 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 SQL e apportare qualsiasi modifica alla subnet potrebbe 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 sottorete 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 intende passare a una subnet non vuota.
È 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
dnsZonePartnerparametro 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 target deve consentire lo stesso traffico di replica richiesto per il gruppo di failover come la subnet sorgente:
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. Assicurati che anche l'intero percorso di rete permetta questo traffico. Un percorso definito dall'utente, un Network Virtual Appliance, un firewall o un altro dispositivo intermedio può comunque bloccare le porte anche quando le regole NSG sono corrette.
La subnet di destinazione non può avere un intervallo di indirizzi sovrapposto a quello della subnet che ospita 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 del passaggio | Descrizione del 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 il ricollegamento dei file di database, il sistema si prepara al failover. Quando tutto è pronto, il sistema esegue un failover con un breve tempo di inattività, in genere inferiore a 10 secondi. |
| Pulizia delle vecchie istanze 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, Azure PowerShell e i comandi di interfaccia della riga di comando di Azure sono stati aggiornati 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 il Riferimento delle API gestite per Istanza gestita di Azure SQL.
È 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.
