Condividi tramite

Panoramica delle operazioni di gestione in Istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure SQL

Questo articolo offre una panoramica delle diverse operazioni che si verificano durante la gestione di Istanza gestita di SQL di Azure. Le operazioni di gestione sono operazioni eseguite nel back-end quando si crea, si aggiorna o si elimina un'istanza di .

Per una descrizione dettagliata dei passaggi e della durata stimata di ogni operazione di gestione, vedere Durata delle operazioni di gestione.

Che cosa sono le operazioni di gestione?

La gestione di Istanza gestita di SQL di Azure prevede le operazioni seguenti:

  • Crea: le operazioni che si verificano quando si crea per la prima volta una nuova istanza gestita di SQL. Ciò include la creazione del gruppo di macchine virtuali sottostanti e la distribuzione del processo del motore di database SQL.
  • Aggiornamento: operazioni che si verificano quando si modificano le proprietà di un'istanza gestita di SQL esistente, ad esempio il ridimensionamento del calcolo o l'archiviazione, la modifica del livello di servizio o l'aggiornamento della configurazione dell'istanza. L'esecuzione di aggiornamenti comporta spesso il ridimensionamento del gruppo di macchine virtuali, l'inserimento dei dati e il failover a un nuovo processo del motore di database SQL.
  • Elimina: operazioni che si verificano quando si elimina un'istanza gestita di SQL esistente, inclusa la pulizia delle risorse, ad esempio il gruppo di macchine virtuali associato all'istanza.

Per una descrizione dettagliata dei passaggi e della durata stimata di ogni operazione di gestione, vedere Durata delle operazioni di gestione.

Le operazioni di gestione di Istanza gestita di SQL vengono eseguite tramite i processi sottostanti seguenti:

  • Operazioni del gruppo di macchine virtuali (VM): operazioni che comportano la creazione e la gestione del gruppo di macchine virtuali sottostanti che ospitano l'istanza gestita di SQL. Sono inclusi il ridimensionamento del gruppo di macchine virtuali, la creazione di nuovi gruppi di macchine virtuali e la gestione delle macchine virtuali all'interno di tali gruppi.
  • Seeding: inizializzazione e sincronizzazione dei dati nei processi del motore di database SQL, in genere per prepararsi a un failover.
  • Failover: Operazioni coinvolte nel deviare il traffico a un altro processo del motore di database SQL, sia nello stesso gruppo di macchine virtuali, sia in un nuovo gruppo.

Operazioni del gruppo di macchine virtuali

Per supportarele distribuzioni all'interno delle reti virtuali di Azure e garantire l'isolamento e la sicurezza per i clienti, Istanza gestita di SQL si basa su cluster virtuali. Il cluster virtuale rappresenta un set dedicato di macchine virtuali isolate distribuite all'interno della subnet di rete virtuale e organizzate all'interno dei gruppi di macchine virtuali. Essenzialmente, ogni istanza gestita di SQL distribuita in una subnet vuota comporta un nuovo cluster virtuale che compila il primo gruppo di macchine virtuali.

Le operazioni di gestione successive sulle istanze gestite di SQL possono influire sui gruppi di macchine virtuali sottostanti. Le modifiche che influiscono sui gruppi di macchine virtuali sottostanti potrebbero influire sulla durata delle operazioni di gestione, perché la distribuzione di più macchine virtuali nel cluster virtuale comporta un sovraccarico da considerare quando si pianificano nuove distribuzioni o aggiornamenti alle istanze esistenti.

Per informazioni dettagliate sull'architettura del cluster virtuale, vedere Architettura del cluster virtuale.

Semina

Il seeding svolge un ruolo fondamentale nel funzionamento di Istanza gestita di SQL di Azure, in particolare durante la configurazione e la replica dei database. Il seeding è il processo che inizializza e sincronizza i dati tra i processi del motore di database SQL, che è una parte fondamentale della gestione delle istanze. Sebbene spesso rappresenti la fase più lunga nelle operazioni lunghe ma di successo, il seeding costituisce un elemento essenziale per stabilire un ambiente di istanza gestita SQL affidabile e funzionale.

Per una durata stimata delle operazioni di seeding, vedere Durata delle operazioni di gestione.

Il processo di seeding prevede in genere le fasi seguenti, indipendentemente dal livello di servizio:

  • Inizializzazione: il sistema identifica il database di origine e di destinazione e avvia una serie di attività che preparano i processi del motore di database SQL per il trasferimento dei dati.
  • Trasferimento dati: i pacchetti di dati effettivi vengono trasferiti dall'origine al processo del motore di database SQL di destinazione, che include una copia completa o parziale del database, a seconda dello scenario.
  • Sincronizzazione: una volta completato il trasferimento iniziale dei dati, il sistema sincronizza eventuali aggiornamenti o modifiche successivi tramite la replica dei blocchi del log delle transazioni per garantire l'integrità dei dati.
  • Convalida e finalizzazione: il processo viene finalizzato e il processo del motore di database SQL di destinazione viene convalidato per confermare la corretta replica e il seeding. Il failover si verifica quando il traffico viene instradato al nuovo processo del motore di database SQL.

Non esiste alcun seeding dei dati nel livello di servizio Per utilizzo generico , tranne quando si modifica il livello di servizio impostandolo sul livello di servizio Business Critical . Le operazioni di gestione nel livello di servizio Utilizzo generico comportano lo scollegamento dell'archiviazione remota dal processo precedente del motore di database SQL e il collegamento al nuovo processo del motore di database SQL.

Al contrario, il livello di servizio Business Critical , progettato per carichi di lavoro ad alte prestazioni, richiede l'archiviazione locale e la codipendenza dei livelli di calcolo e archiviazione. Di conseguenza, quasi ogni operazione e scenario in questo livello di servizio richiede il seeding per garantire la disponibilità e la coerenza dei dati.

L'attivazione o meno del seeding dipende dallo scenario specifico e dal livello di servizio, ad esempio:

  • Livelli di servizio per utilizzo generico e per utilizzo generico di prossima generazione :
    • Passaggio al livello di servizio Business Critical : i dati devono essere trasferiti dalla risorsa di archiviazione remota alla risorsa di archiviazione locale usata nel livello di servizio Utilizzo generico.
    • Abilitazione o disabilitazione della ridondanza della zona : i dati devono essere copiati in o dalle aree con ridondanza della zona.
  • Livello di servizio Business Critical:
    • Ridimensionamento dell'archiviazione: poiché l'archiviazione è fisicamente collegata al computer locale, ogni modifica di archiviazione richiede la creazione di un nuovo gruppo di macchine virtuali, pertanto i dati devono essere trasferiti dal computer precedente al nuovo computer (in tutte e 4 le repliche).
    • Ridimensionamento dei vCore: ogni operazione di ridimensionamento del calcolo richiede la creazione di un nuovo gruppo di macchine virtuali, quindi i dati devono essere copiati dal computer precedente al nuovo computer (in tutte e 4 le repliche).
    • Modifica dell'hardware o della finestra di manutenzione: se esiste già un gruppo di macchine virtuali all'interno della subnet con una configurazione corrispondente, il gruppo di macchine virtuali viene ridimensionato. Se si tratta di una nuova configurazione, viene creato un nuovo gruppo di macchine virtuali. I dati devono essere copiati dal gruppo di macchine virtuali precedente al nuovo gruppo di macchine virtuali (in tutte e 4 le repliche).
    • Modifica del livello di servizio: i dati devono essere copiati dall'archiviazione locale all'archiviazione remota usata nel livello di servizio Utilizzo generico.
    • Abilitazione o disabilitazione della ridondanza della zona : i dati devono essere copiati in o dalle aree con ridondanza della zona.

Velocità di seeding

I fattori seguenti influiscono sulla durata del processo di seeding:

  • Dimensioni del database: i database di dimensioni maggiori richiedono più tempo per trasferire i dati e sincronizzare i dati tra i processi del motore di database SQL.
  • Dipendenze di rete: la larghezza di banda e latenza di rete possono influire significativamente sulla velocità di seeding.
  • Operazioni di backup e ripristino: le operazioni di backup in corso nel processo del motore di database SQL di origine possono influenzare la preparazione dei dati da inviare a un altro processo del motore di database SQL.
  • Carico di lavoro dell'istanza: Il carico di lavoro dell'istanza durante il seeding può causare rallentamenti e prolungare gravemente il processo.

Sebbene la maggior parte di questi fattori esula dal controllo, è possibile gestire il traffico delle istanze per ottimizzare significativamente la velocità di seeding. Il seeding usa le stesse risorse di calcolo dell'istanza che gestiscono il traffico dell'istanza. Il traffico intenso durante il seeding può ridurre la disponibilità di vCore, portando a una capacità insufficiente per il processo di seeding e provocando la limitazione.

Il traffico elevato durante il seeding può influire sulla sincronizzazione perché il seeding è progettato per creare un pacchetto e trasferire tutti i dati attualmente archiviati in un'unica operazione. Le successive modifiche ai dati apportate al processo precedente del motore di database SQL che arrivano dopo l'avvio del seeding devono essere sincronizzate con il nuovo processo del motore di database SQL in modo incrementale tramite la replica a blocchi del log delle transazioni prima che possa verificarsi il failover. Se l'istanza è sottoposta a un carico elevato, il seeding potrebbe avere difficoltà a tenere il passo con i dati in ingresso, causando ritardi e potenziali errori nella fase di sincronizzazione. Il traffico elevato continuo nel processo precedente del motore di database SQL dopo l'avvio del seeding può causare una situazione in cui la fase di sincronizzazione non viene mai completata, perché i nuovi dati continuano ad arrivare e devono essere trasferiti. Ciò può comportare un ciclo perpetuo di trasferimento dei dati che impedisce il failover al nuovo processo del motore di database SQL.

Per una durata stimata delle operazioni di seeding, vedere Durata delle operazioni di gestione.

Infrastruttura e avvisi di Azure

Il seeding è un processo che non può essere quantificato con precisione né previsto rigorosamente, perché si basa sui servizi di Azure condivisi. Le operazioni di trasferimento e seeding dei dati dipendono da vari servizi e infrastrutture di Azure interni, condivisi nell'intero ecosistema di Azure. Questi servizi vengono usati da numerosi altri servizi non correlati all'interno di Azure. Tutti i servizi all'interno dell'ecosistema di Azure competono per le risorse disponibili, che causano fluttuazioni nella disponibilità momentanea influenzata da più fattori. Anche se Microsoft può fornire un intervallo in cui opera la capacità dell'infrastruttura, l'esecuzione di stime precise è complessa.

Ripristino automatico

Il failover dell'istanza è il momento in cui il traffico viene indirizzato da un processo esistente del motore di database SQL a un nuovo processo del motore di database SQL all'interno del gruppo di nodi in un gruppo di VM che include l'istanza SQL gestita. Il failover è una parte fondamentale della maggior parte delle operazioni di gestione, soprattutto quando si aggiorna un'istanza di . Il breve momento di interruzione delle connessioni mentre il traffico viene reindirizzato al nuovo processo del motore di database SQL viene definito failover.

L'istanza non è disponibile solo durante il failover, quando il traffico viene reindirizzato al nuovo processo del motore di database SQL. Nel livello di servizio Business Critical l'istanza non è disponibile per un massimo di 20 secondi, mentre nel livello di servizio Utilizzo generico l'istanza può non essere disponibile per un massimo di 2 minuti. Tutte le operazioni back-end che si verificano per preparare il failover a causa di operazioni di gestione, ad esempio la reinizializzazione dei database nel livello di servizio Business Critical, vengono eseguite in background e non compromettono la disponibilità dell'istanza.

Importante

Per le operazioni di aggiornamento che non vengono completate, ma che comportano il ricollegamento del database (ad esempio, il ridimensionamento di vCore, la scalabilità della memoria, la modifica dell'hardware o la finestra di manutenzione), la durata del failover dei database nel livello di servizio Per utilizzo generico di nuova generazione viene ridimensionata con il numero di database, fino a 10 minuti. Mentre l'istanza diventa disponibile dopo 2 minuti, alcuni database potrebbero essere disponibili dopo un ritardo. La durata del failover viene misurata dal momento in cui il primo database diventa offline, fino al momento in cui l'ultimo database viene online. Il livello di servizio Per utilizzo generico di nuova generazione aumenta il numero massimo di database per istanza da 100 a 500.

Le differenze architetturali tra i livelli di servizio sono illustrate in modo approfondito nella disponibilità.

Effetti incrociati sulle operazioni di gestione

Le operazioni di gestione in un'istanza gestita di SQL possono influire sulle operazioni di gestione di altre istanze posizionate all'interno della stessa subnet:

  • Le operazioni di ripristino prolungate in un cluster virtuale mettono in attesa altre operazioni nello stesso cluster virtuale, come le operazioni di creazione o ridimensionamento.

    Esempio: Se è presente un'operazione di ripristino a esecuzione prolungata e anche una richiesta di scalabilità che riduce il gruppo di macchine virtuali, il completamento della richiesta di compattazione richiede più tempo perché attende il completamento dell'operazione di ripristino prima che possa continuare.

  • Una successiva operazione di creazione o ridimensionamento dell'istanza viene messa in attesa da una creazione o una scalabilità di istanze avviata in precedenza che ha avviato un ridimensionamento del gruppo di macchine virtuali.

    Esempio: Se sono presenti più richieste di creazione e/o ridimensionamento nella stessa subnet nello stesso gruppo di macchine virtuali e una di esse avvia il ridimensionamento di un gruppo di macchine virtuali, tutte le richieste inviate 1+ minuti dopo l'ultima richiesta di operazione iniziale durano più tempo del previsto, perché queste richieste devono attendere il completamento del ridimensionamento prima della ripresa.

  • Le operazioni di creazione/scalabilità inviate in una finestra di 1 minuto vengono raggruppate ed eseguite in parallelo.

    Esempio: Viene eseguito un solo ridimensionamento del cluster virtuale per tutte le operazioni inviate in una finestra di 1 minuto (misurato dal momento in cui viene inviata la prima richiesta di operazione). Se un'altra richiesta viene inviata più di 1 minuto dopo l'invio della prima, attende il completamento del ridimensionamento del cluster virtuale prima dell'avvio dell'esecuzione.

Importante

Le operazioni di gestione in attesa a causa di un'altra operazione in corso vengono automaticamente riprese dopo che vengono soddisfatte le condizioni per procedere. Non è necessaria alcuna azione da parte dell'utente per riprendere le operazioni di gestione temporaneamente sospese.

Monitorare le operazioni di gestione

Per informazioni su come monitorare l'avanzamento e lo stato delle operazioni di gestione, vedere Monitoraggio delle operazioni di gestione di Azure SQL Istanza Gestita.

Annullare le operazioni di gestione

Per informazioni su come annullare l'operazione di gestione, vedere Annullamento delle operazioni di gestione di Istanza gestita di Azure SQL.

Contenuto correlato

  • Last updated on