Condividi tramite

Migrazione automatica da Database PostgreSQL di Azure - Da server singolo a server flessibile

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server singolo

La migrazione automatica da Database di Azure per PostgreSQL : server singolo a server flessibile è una migrazione avviata dal servizio che viene eseguita durante una finestra di inattività pianificata per il server singolo, separata dalla relativa finestra di applicazione di patch o manutenzione. Il servizio identifica i server idonei e invia notifiche avanzate con passaggi dettagliati sul processo di migrazione automatica. È possibile esaminare e modificare la pianificazione della migrazione, se necessario o inviare una richiesta di supporto per rifiutare esplicitamente la migrazione automatica per i server.

La migrazione automatica sfrutta il servizio di migrazione di Azure PostgreSQL per offrire una migrazione offline resiliente durante la finestra di migrazione pianificata. Il tempo di inattività varia in base alle caratteristiche del carico di lavoro, con carichi di lavoro più grandi che richiedono fino a 20 minuti. Per i benchmark di velocità della migrazione, vedere Benchmarking della velocità di migrazione di Azure PostgreSQL. Questa migrazione elimina la necessità di eseguire la migrazione manuale del server, consentendo di sfruttare le funzionalità del server flessibile dopo la migrazione, tra cui prestazioni di prezzo migliorate, controllo granulare della configurazione del database e finestre di manutenzione personalizzate.

Nota

Il servizio di migrazione automatica seleziona Server singolo di cui eseguire la migrazione in base ai criteri seguenti:

  • Server singolo versione 11
  • Server senza funzionalità complesse, ad esempio CMK, Microsoft Entra ID, Replica di lettura e endpoint privato
  • Dimensioni dei dati <= 10 GB
  • Accesso pubblico è attivato

Processo di migrazione automatica

Il processo di automigration include diverse fasi chiave:

  • Creazione di server flessibili di destinazione: viene creato un server flessibile in modo che corrisponda alle prestazioni e ai costi dello SKU del server singolo. Eredita tutte le regole del firewall dal server singolo di origine.

  • Migrazione dei dati: la migrazione dei dati viene eseguita durante la finestra di migrazione designata, in genere pianificata al di fuori dell'orario di ufficio per l'area di hosting del server (se la finestra viene scelta dal servizio). Il server singolo di origine è impostato su sola lettura e tutti i dati, gli schemi, i ruoli utente, i privilegi e la proprietà degli oggetti di database vengono migrati nel server flessibile.

  • Commutatore DNS: dopo la migrazione dei dati, viene eseguito un commutatore DNS, consentendo al server singolo esistente stringa di connessione di connettersi senza problemi al nuovo server flessibile. I formati server singolo e flessibile stringa di connessione, nonché i formati di nome utente (username@server_name e nome utente) sono supportati nel server flessibile migrato.

  • Visibilità server flessibile: dopo una corretta migrazione dei dati e un commutatore DNS, il nuovo server flessibile viene visualizzato nella sottoscrizione e può essere gestito tramite il portale di Azure o l'interfaccia della riga di comando.

  • Stringhe di connessione a server singolo aggiornate: le stringa di connessione aggiornate per il server singolo legacy vengono inviate tramite notifiche di integrità dei servizi nel portale di Azure. Sono accessibili anche nella pagina Portale server singolo in Impostazioni -> Stringhe di connessione.

  • Eliminazione server singolo: il server singolo viene conservato per sette giorni dopo la migrazione prima dell'eliminazione.

Nomina di server singoli per l'Automigrazione

Il processo di candidatura è destinato agli utenti che vogliono monitorare volontariamente la migrazione al server flessibile. Se si è proprietari di un carico di lavoro a server singolo, ora è possibile candidarsi (se non è già pianificato dal servizio) per l'archiviazione automatica. Inviare i dettagli del server tramite questo modulo.

Come verificare se il server singolo è pianificato per l'archiviazione automatica

Per determinare se il server singolo è selezionato per la migrazione automatica, seguire questa procedura:

  • Notifiche sull'integrità dei servizi: nella portale di Azure passare a Eventi di manutenzione pianificata per l'integrità > dei servizi. Cercare gli eventi con l'etichetta "Notifica per la migrazione automatica pianificata a Database di Azure per PostgreSQL server singolo". Le notifiche vengono inviate 30, 14 e 7 giorni prima della data di migrazione e di nuovo durante le fasi di migrazione: in corso, completate e sei giorni prima che il server singolo venga rimosso.

Nota

Queste notifiche non vengono visualizzate nella posta in arrivo per impostazione predefinita. Per riceverli tramite posta elettronica o SMS, è necessario configurare gli avvisi di integrità dei servizi seguendo questa procedura qui

  • Pagina Panoramica server singolo : passare all'istanza di Server singolo nella portale di Azure e selezionare la pagina Panoramica. Se pianificato per l'automigration, sono disponibili i dettagli qui, inclusa un'opzione per rinviare la migrazione di un mese alla volta o riprogrammare entro il mese corrente.

Nota

La pianificazione della migrazione verrà bloccata 7 giorni prima della finestra di migrazione pianificata, nel corso dei quali non sarà possibile riprogrammarla.

  • Notifiche tramite posta elettronica di Azure CXP- Esperienza cliente di Azure (CXP) invia anche messaggi di posta elettronica diretti ai ruoli classici e ai ruoli controllo degli accessi in base al ruolo associati alla sottoscrizione contenente il server singolo, fornendo informazioni sulle future automigrazioni.

Controlli dei prerequisiti per la migrazione automatica

Esaminare i prerequisiti seguenti per garantire una corretta migrazione automatica:

  • Lo stato dell'istanza del server singolo deve essere pronto ("ready state") durante la finestra di migrazione pianificata per l'esecuzione della migrazione automatica.
  • Per l'istanza del server singolo con SSL abilitato, assicurarsi di avere tutti i certificati (CA radice DigiCertGlobalRootG2, CA radice DigiCertGlobalRootCA) disponibili nell'archivio radice attendibile. Inoltre, se il certificato è stato aggiunto alla stringa di connessione, creare un certificato CA combinato con tutti e tre i certificati prima della migrazione automatica pianificata per garantire la continuità aziendale dopo la migrazione.
  • Se l'istanza del server singolo di origine di Database di Azure per PostgreSQL ha nomi di regole del firewall superiori a 80 caratteri, rinominarle per garantire che la lunghezza del nome sia inferiore a 80 caratteri. La lunghezza per i nomi delle regole del firewall supportata nel server flessibile è di 80 caratteri, mentre nel server singolo la lunghezza consentita è di 128 caratteri.

Come viene effettuato il provisioning del server flessibile postgresql di destinazione?

Il provisioning del livello di calcolo e dello SKU del server flessibile di destinazione viene eseguito in base al piano tariffario e ai VCore del server singolo di origine, come illustrato di seguito.

Piano tariffario Server singolo vCore Server singolo Livello del server flessibile Nome SKU del server flessibile
Di base 1 Con possibilità di burst B1ms
Di base 2 Con possibilità di burst B2s
Utilizzo generico 2 Utilizzo generico Standard_D2s_v3
Utilizzo generico 4 Utilizzo generico Standard_D4s_v3
Utilizzo generico 8 Utilizzo generico Standard_D8s_v3
Utilizzo generico 16 Utilizzo generico Standard_D16s_v3
Utilizzo generico 32 Utilizzo generico Standard_D32s_v3
Utilizzo generico 64 Utilizzo generico Standard_D64s_v3
Con ottimizzazione per la memoria 2 MemoryOptimized Standard_E2s_v3
Con ottimizzazione per la memoria 4 MemoryOptimized Standard_E4s_v3
Con ottimizzazione per la memoria 8 MemoryOptimized Standard_E8s_v3
Con ottimizzazione per la memoria 16 MemoryOptimized Standard_E16s_v3
Con ottimizzazione per la memoria 32 MemoryOptimized Standard_E32s_v3
  • La versione postgresql, l'area, la stringa di connessione, la sottoscrizione e il gruppo di risorse per il server flessibile di destinazione rimarranno uguali a quelli del server singolo di origine.
  • Per i server singoli con spazio di archiviazione inferiore a 20 GiB, le dimensioni di archiviazione sono impostate su 32 GiB, corrispondenti al limite di archiviazione minimo per il server flessibile di Database di Azure per PostgreSQL.
  • Per i server singoli con un requisito di archiviazione maggiore, con spazio di archiviazione sufficiente equivalente a 1,25 volte o al 25% di spazio di archiviazione in più rispetto a quello usato nel server singolo. Durante la copia di base iniziale dei dati, vengono eseguite più istruzioni insert nella destinazione, che generano WAL (Write Ahead Logs). Finché questi log di write-ahead non vengono archiviati, i log utilizzano l'archiviazione nella destinazione e quindi il margine di sicurezza.
  • Entrambi i formati, nomeutente@nome_server (server singolo) e nomeutente (server flessibile) sono supportati nel server flessibile migrato.
  • Entrambi i formati di stringa di connessione per server singolo e server flessibile sono supportati nel server flessibile migrato.

Passaggi post-migrazione

Ecco le informazioni necessarie per pubblicare la migrazione automatica:

  • I parametri del server nel server flessibile vengono ottimizzati per gli standard della community. Se si desidera mantenere gli stessi valori dei parametri del server singolo, è possibile accedere tramite PowerShell ed eseguire lo script qui per copiare i valori dei parametri.
  • Per abilitare le informazioni dettagliate sulle prestazioni delle query, è necessario abilitare Query Store nel server flessibile, funzionalità non abilitata per impostazione predefinita
  • Se è necessaria la disponibilità elevata, è possibile abilitarla con tempi di inattività pari a zero.

Gestione delle regole della rete virtuale nel server flessibile

In Database di Azure per PostgreSQL server singolo, una regola di rete virtuale (VNet) è una subnet elencata nell'elenco di controllo di accesso (ACL) del server. Questa regola consente al server singolo di accettare la comunicazione dai nodi all'interno di tale subnet specifica. Per il server flessibile, le regole della rete virtuale non sono supportate. Il server flessibile consente invece la creazione di endpoint privati, consentendo al server di funzionare all'interno della rete virtuale. Un endpoint privato assegna un indirizzo IP privato al server flessibile e tutto il traffico tra la rete virtuale e il server viaggia in modo sicuro tramite la rete backbone di Azure, eliminando la necessità di esposizione a Internet pubblica.

Dopo la migrazione, è necessario aggiungere un endpoint privato al server flessibile per tutte le subnet precedentemente coperte dalle regole della rete virtuale nel server singolo. È possibile completare questo processo usando il portale di Azure o l'interfaccia della riga di comando di Azure. Al termine di questo passaggio, la connettività di rete rimarrà intatta nel server flessibile dopo la migrazione da server singolo.

Domande frequenti (FAQ)

D. Per quale motivo viene eseguita la migrazione automatica?

R. L'istanza di Server singolo di Database di Azure per PostgreSQL è idonea per la migrazione automatica all'offerta principale di Server flessibile di Database di Azure per PostgreSQL. Questa migrazione automatica rimuoverà il sovraccarico per eseguire manualmente la migrazione del server. È possibile sfruttare i vantaggi del server flessibile, tra cui prezzi e prestazioni migliori, un controllo granulare sulla configurazione del database e finestre di manutenzione personalizzate.

D. Come avviene la migrazione automatica? Quali elementi vengono migrati?

R. Viene effettuato il provisioning di Server flessibile in modo che corrisponda strettamente agli stessi VCore e alle stesse risorse di archiviazione di Server singolo. Successivamente il server singolo di origine viene inserito in uno stato di sola lettura, lo schema e i dati vengono copiati nel server flessibile di destinazione. Viene effettuato uno switch DNS per instradare tutte le connessioni esistenti verso la destinazione, e il Server flessibile viene portato online. La migrazione automatica esegue la migrazione dei database (inclusi schema, dati, utenti/ruoli e privilegi). La migrazione è offline quando si riscontrano tempi di inattività fino a 20 minuti.

D. Come è possibile configurare o visualizzare gli avvisi di migrazione automatica?

R. Di seguito sono riportati i modi in cui è possibile configurare gli avvisi:

  • Configurare gli avvisi di integrità dei servizi per ricevere notifiche di pianificazione e stato della migrazione sul posto tramite posta elettronica/SMS seguendo questa procedura.
  • Controllare la notifica di migrazione automatica nel portale di Azure seguendo questa procedura.

D. Come è possibile rinviare la migrazione pianificata del server singolo?

R. È possibile esaminare la pianificazione della migrazione passando al pagina di Panoramica dell'istanza del Server singolo. Se si vuole rinviare la migrazione, è possibile rinviarla al massimo di un mese passando alla pagina Panoramica dell'istanza del server singolo nel portale di Azure. È possibile riprogrammare la migrazione selezionando un'altra finestra di migrazione entro un mese. I dettagli della migrazione verranno bloccati sette giorni prima della finestra di migrazione pianificata, dopo i quali non sarà possibile riprogrammarla. Questa migrazione automatica può essere posticipata mensilmente fino al 30 marzo 2025.

D. Come è possibile rifiutare esplicitamente una migrazione automatica pianificata del server singolo?

R. Se si desidera rifiutare esplicitamente la migrazione automatica, è possibile generare un ticket di supporto mirato a tale scopo.

D. Quale nome utente e stringa di connessione sono supportate per il Server flessibile migrato? ​​

R. Entrambi i formati di nome utente nomeutente@nome_server (formato per il server singolo) e nomeutente (formato per il server flessibile) sono supportati per il server flessibile migrato e quindi non è necessario aggiornarli per mantenere la continuità dell'applicazione dopo la migrazione. Inoltre, entrambi i formati di stringa di connessione (formato per il server singolo e flessibile) saranno supportati anche per il server flessibile migrato.

D. È prevista una differenza di prezzo nel potenziale passaggio dal Server singolo di base al Server flessibile postgresql?

R. Alcuni server potrebbero visualizzare una revisione dei prezzi secondaria dopo la migrazione perché il limite di archiviazione minimo per entrambe le offerte è diverso (5 GiB su server singolo e 32 GiB nel server flessibile). Il costo di archiviazione per il server flessibile è appena superiore a quello del server singolo. Qualsiasi aumento dei prezzi viene compensato attraverso una velocità effettiva e prestazioni migliori rispetto al server singolo. Per altre informazioni sui prezzi dei server flessibili, vedere questo documento

Contenuto correlato