Condividi tramite

Discipline di aggiornabilità per le Istanza gestita di SQL abilitate per Azure Arc

  • Articolo

I servizi dati abilitati per Azure Arc consentono di ottenere una versione sempreverdi di SQL disponibile solo nelle Istanza gestita di SQL abilitate per Arc. Per natura, i Istanza gestita di SQL abilitati per Arc offrono una aggiornabilità basata su servizi gestiti, in modo da poter trarre vantaggio dall'innovazione nell'infrastruttura di Azure non appena è disponibile, a differenza delle installazioni locali o degli ambienti multicloud.

Questo articolo fornisce considerazioni chiave sulla progettazione e consigli per la configurazione e la gestione del processo di aggiornamento per i servizi dati abilitati per Azure Arc.

Architettura

Modalità direttamente connessa

Il diagramma seguente mostra il flusso di aggiornamento del servizio dati in modalità connessa diretta .

Screenshot che mostra il flusso di aggiornamento del servizio dati in modalità connessa diretta.

Modalità connessa indirettamente

Il diagramma seguente mostra il flusso di aggiornamento del servizio dati in modalità connessa indirettamente .

Screenshot che mostra il flusso di aggiornamento del servizio dati in modalità connessa indirettamente.

Livello di servizio Utilizzo generico

I diagrammi seguenti mostrano il processo di aggiornamento per le Istanza gestita di SQL abilitate per Arc in un livello di servizio per utilizzo generico.

Screenshot che mostra il processo di pre-aggiornamento di un Istanza gestita di SQL abilitato per Arc in un livello di servizio per utilizzo generico.

Screenshot che mostra il processo di aggiornamento di un Istanza gestita di SQL abilitato per Arc in un livello di servizio per utilizzo generico.

Livello di servizio business critical

I diagrammi seguenti mostrano il processo di aggiornamento per le Istanza gestita di SQL abilitate per Arc in un livello di servizio business critical.

Screenshot che mostra il processo di pre-aggiornamento di un Istanza gestita di SQL abilitato per Arc in un livello di servizio business critical.

Screenshot che mostra il processo di aggiornamento di un Istanza gestita di SQL abilitato per Arc in un livello di servizio business critical.

Screenshot che mostra l'implementazione dell'aggiornamento delle repliche secondarie rimanenti in un aggiornamento del livello di servizio business critical.

Screenshot che mostra il failover a livello di SQL e l'ultima creazione di istanze del pod in un aggiornamento del livello di servizio business critical.

Considerazioni relative alla progettazione

Aggiornamenti del controller di dati di Azure Arc

  • Gli aggiornamenti possono essere eseguiti usando vari strumenti, ad esempio l'interfaccia della riga di comando di Azure, portale di Azure o Kubernetes. Si consideri lo strumento da usare a seconda della modalità di connettività usata, direttamente o indirettamente connessa e dello strumento con cui si ha più familiarità.
  • Esaminare il controller di dati di Azure Arc per verificare se sono presenti servizi dati di anteprima, ad esempio PostgreSQL con abilitazione di Azure Arc, distribuiti insieme alle Istanza gestita di SQL abilitate per Arc. Non è possibile eseguire aggiornamenti sul posto se si dispone di una combinazione di servizi di anteprima e disponibili a livello generale distribuiti nello stesso titolare del trattamento dei dati.
  • Esaminare le versioni di tutte le istanze gestite di SQL abilitate per Arc usate dal controller di dati per verificare che siano nella stessa versione del controller di dati prima di eseguire l'aggiornamento.
  • Prendere in considerazione il percorso di aggiornamento supportato per determinare la versione corretta successiva per il titolare del trattamento dei dati prima dell'aggiornamento.

Nota

Un aggiornamento del controller di dati di Azure Arc non causa tempi di inattività per il Istanza gestita di SQL abilitato per Arc.

Modalità direttamente connessa

Modalità connessa indirettamente

  • Determinare se l'aggiornamento del controller dati di Azure Arc in modalità connessa indirettamente deve essere implementato usando l'interfaccia della riga di comando di Azure o gli strumenti Kubernetes.
  • Esaminare i prerequisiti per gli aggiornamenti usando gli strumenti Kubernetes e l'interfaccia della riga di comando di Azure.
  • Decidere se si userà Registro artefatti Microsoft nel caso in cui i cluster dispongano di connettività Internet o di un registro privato se i cluster vengono troncato per eseguire il pull delle immagini dei servizi dati abilitate per Azure Arc.
  • Pianificare le autorizzazioni Kubernetes necessarie per l'account del servizio usato per aggiornare il controller di dati di Azure Arc usando gli strumenti Kubernetes.
  • Controllare le informazioni sul repository per assicurarsi che siano valide e che siano già state estratte nuove immagini.

Aggiornamenti di Istanza gestita di SQL abilitati per Azure Arc

Considerazioni generali

  • Prima di aggiornare il Istanza gestita di SQL abilitato per Arc, è necessario eseguire gli aggiornamenti al controller di dati di Azure Arc. L'estensione del cluster arcdata e le versioni delle estensioni Istanza gestita di SQL sono correlate e devono essere uguali.
  • Decidere se si useranno gli aggiornamenti automatici o manuali del Istanza gestita di SQL abilitato per Arc a seconda dei requisiti.
  • Nel caso degli aggiornamenti automatici, è possibile definire solo una singola finestra di manutenzione per un titolare del trattamento dei dati. Considerare il numero di finestre di manutenzione diverse necessarie per carichi di lavoro diversi per identificare il numero di titolari dei dati necessari.

Livello di servizio Utilizzo generico

  • Durante un aggiornamento per utilizzo generico livello di servizio, il pod Kubernetes viene terminato e sottoposto a nuovo provisioning con la nuova versione. È importante comprendere l'applicazione e l'effetto collaterale del client di un aggiornamento in cui si verifica un breve tempo di inattività durante la creazione del nuovo pod.
  • Esaminare l'architettura delle applicazioni per capire se hanno la resilienza necessaria e la logica di ripetizione dei tentativi per supportare un breve impatto durante un aggiornamento.

Livello di servizio business critical

  • Durante un aggiornamento business critical livello di servizio con più repliche, le repliche secondarie vengono aggiornate per prime. Una delle repliche secondarie aggiornate viene alzata di livello per diventare la nuova replica primaria mentre la replica primaria precedente diventa secondaria e viene aggiornata. Durante la transizione dal database primario precedente al nuovo database primario, si verifica un breve momento di inattività quando si verifica il failover. È importante comprendere l'applicazione e l'impatto lato client di un aggiornamento quando si verifica il failover.
  • Esaminare l'architettura dell'applicazione per capire se hanno la resilienza necessaria e la logica di ripetizione dei tentativi per supportare un breve impatto durante un aggiornamento.

Suggerimenti per la progettazione

Aggiornamenti del controller di dati di Azure Arc

  • Se si esegue l'aggiornamento usando l'interfaccia della riga di comando di Azure, verificare che la versione dell'estensione dell'interfaccia della riga di comando di Azure arcdata corrisponda alla versione di cui si vuole eseguire l'aggiornamento nel log delle versioni.

  • Negli ambienti multi-cluster eseguire prima gli aggiornamenti in un ambiente di test/sviluppo per convalidare eventuali problemi o modifiche di rilievo.

  • Eseguire un'esecuzione a secco prima dell'aggiornamento per convalidare lo schema della versione, il token di autorizzazione del repository privato, se usato, e che il Registro di sistema esiste prima di tentare un aggiornamento effettivo.

  • Creare un processo di monitoraggio per i nuovi aggiornamenti del controller di dati di Azure Arc.

  • Non combinare le Istanza gestita di SQL abilitate per PostgreSQL e Arc nello stesso controller di dati perché PostgreSQL è ancora in anteprima mentre le Istanza gestita di SQL abilitate per Arc sono disponibili a livello generale. Prendere in considerazione un cluster separato con il proprio controller di dati per testare PostgreSQL.

  • Evitare di usare le funzionalità di anteprima nell'ambiente di produzione e usare solo le funzionalità di anteprima per scopi di valutazione nelle istanze di sviluppo/test.

  • Creare un inventario delle versioni correnti dei titolari dei dati distribuiti. Azure Resource Graph può essere usato per eseguire query sui titolari dei dati distribuiti correnti.

      resources
  | where type == 'microsoft.azurearcdata/datacontrollers'
  | extend version = tostring(properties.k8sRaw.status.runningVersion)
  | project name,location,resourceGroup,version

  • Esaminare la guida alla risoluzione dei problemi per comprendere come ottenere i log necessari per risolvere eventuali problemi di aggiornamento.

Modalità direttamente connessa

Modalità connessa indirettamente

Aggiornamenti di Istanza gestita di SQL abilitati per Azure Arc

Indicazioni generali

  • Mantenere aggiornato il Istanza gestita di SQL abilitato per Arc con la versione più recente disponibile per ricevere le patch, le correzioni di bug e le funzionalità più recenti. Attualmente, i servizi dati Arc non supportano l'omissione delle versioni durante gli aggiornamenti. Pertanto, se sono presenti più versioni da aggiornare, è necessario eseguire l'aggiornamento alle versioni sequenziali per ottenere la versione più recente. È consigliabile non allontanarsi troppo dalle versioni più recenti.

  • Assicurarsi di aver configurato i criteri di backup "ripristino temporizzato" in modo che sia possibile eseguire il ripristino in caso di problemi durante un aggiornamento. Esaminare l'area di progettazione critica per la continuità aziendale e il ripristino di emergenza e usare il kubectl describe sqlmi comando sulle istanze per verificare le impostazioni di conservazione correnti.

  • In ambienti o scenari multi-cluster con più distribuzioni di Istanza gestita di SQL con abilitazione di Arc che rappresentano ambienti diversi, eseguire gli aggiornamenti prima in ambienti di sviluppo/test, ad esempio l'ambiente di sviluppo, per convalidare eventuali potenziali problemi o modifiche di rilievo.

  • Eseguire un'esecuzione a secco prima dell'aggiornamento per convalidare lo schema della versione, il token di autorizzazione del repository privato, se usato, e che il Registro di sistema esiste prima di tentare un aggiornamento effettivo.

  • Usare l'interfaccia della riga di comando di Azure per eseguire aggiornamenti su larga scala delle Istanza gestita di SQL abilitate per Arc.

  • Usare gli aggiornamenti automatici per i carichi di lavoro che possono tollerare aggiornamenti immediati e rifiutare esplicitamente gli aggiornamenti automatici per i carichi di lavoro che richiedono un'ora di minore attività pianificata per eseguire l'aggiornamento.

  • Se vengono usati gli aggiornamenti automatici, assicurarsi di definire una finestra di manutenzione appropriata per consentire l'esecuzione degli aggiornamenti durante le ore di minore attività.

  • In caso di aggiornamenti manuali, assicurarsi di stabilire una cadenza regolare per eseguire gli aggiornamenti per rimanere all'interno delle versioni supportate.

    Nota

    È anche possibile eseguire il polling del Registro artefatti Microsoft per le nuove versioni delle immagini del contenitore.

  • Creare un processo per monitorare lo stato di aggiornamento usando l'interfaccia della riga di comando di Azure o gli strumenti Kubernetes.

  • Esaminare le versioni corrispondenti dei diversi componenti prima di eseguire un aggiornamento per verificare che siano presenti le versioni corrette dei componenti.

Livello di servizio Utilizzo generico

Livello di servizio business critical

  • Distribuire l'istanza di business critical con tre repliche anziché due per ottenere una maggiore disponibilità e un minor tempo di inattività durante le attività di aggiornamento e failover.
  • Eseguire gli aggiornamenti durante le ore non critiche per ridurre al minimo l'impatto sugli utenti e sui dati dell'organizzazione.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti: