Analizzare i criteri decisionali per la selezione degli strumenti e il modello di migrazione
Dopo avere esaminato le opzioni per le metodologie di migrazione e le opzioni per gli strumenti, è ora possibile esplorare i criteri decisionali da valutare per eseguire le migrazioni a Database di Azure per PostgreSQL - Server flessibile. I tre criteri principali che agevolano la scelta sono tempo di inattività, percorso di origine dei database e personalizzabilità.
Tempi di fermo
Il tempo di inattività è un aspetto fondamentale delle attività di migrazione e la durata accettabile per gli stakeholder consente di decidere se è necessario eseguire un'attività di migrazione offline oppure online.
Le attività di migrazione vengono in genere pianificate in anticipo per garantire che i controlli delle modifiche appropriati e la governance associata siano completati per l'attività. Questa pianificazione consente un dialogo con gli stakeholder chiave per comprendere per quanto tempo il sistema può essere offline. In questo caso è consigliabile sapere quanto tempo è richiesto per le diverse opzioni. È possibile stabilire le durate di tempo di inattività minime e massime stimate.
Stabilire il tempo di inattività minimo necessario per eseguire un cutover dell'applicazione è fondamentale. In definitiva, questa valore indica la quantità di tempo per cui il sistema deve rimanere offline anche per un'attività di migrazione online (o con tempo di inattività minimo). La complessità dell'applicazione determinerà queste tempistiche. Per un'applicazione relativamente semplice, questo processo potrebbe essere costituito da arresto di un servizio, aggiornamento di un file di configurazione e quindi riattivazione. In ambienti più complessi questo processo può richiedere molto più tempo se sono coinvolti più server e livelli applicazione.
Comprendere la durata necessaria per le attività di migrazione online oppure offline è l'altro elemento importante correlato al tempo di inattività. Se si tratta di una migrazione offline, il tempo di inattività corrisponde al tempo impiegato per estrarre, trasferire e caricare i dati dall'origine alla destinazione e quindi per la convalida e la verifica. Questo tempo di inattività viene quindi inserito tra il tempo necessario per disattivare l'app o il carico di lavoro e il tempo impiegato per riattivare l'app o il carico di lavoro.
Se si tratta di migrazioni online (tempo di inattività minimo), il tempo di inattività è la durata necessaria per sincronizzare le modifiche finali dall'origine alla destinazione dopo la disattivazione dell'applicazione. Aggiungere a tale tempo di inattività le attività di convalida e verifica prima di riconfigurare e abilitare l'applicazione o il carico di lavoro.
Dopo avere ottenuto queste informazioni, è possibile esaminare gli elementi tecnici della migrazione per stabilire quali sono le opzioni appropriate.
Percorso di origine dei database
Il percorso di origine dei database di cui eseguire la migrazione è rilevante a causa dei vincoli che potrebbero essere applicati per una determinata configurazione.
Origini locali o non di Azure
Per un database locale o non di Azure, il vincolo di chiave è in genere la connettività di rete tra origine e destinazione. I tre punti da considerare sono la larghezza di banda, la latenza e il volume di dati. Dopo aver compreso questi punti, è possibile prendere una decisione basata su informazioni aggiornate per il tipo di migrazione appropriato.
Se il volume di dati di cui eseguire la migrazione è elevato e, in proporzione, la larghezza di banda è ridotta, non sarà probabilmente possibile scegliere un semplice dump e ripristino. Se invece il volume di dati è elevato e larghezza di banda è ampia, la situazione è meno problematica.
Analogamente, se si tratta di una migrazione online in cui verrà eseguita la sincronizzazione dei dati, la latenza è uno dei fattori chiave. Se la latenza è elevata, potrebbe verificarsi un impatto negativo sulle prestazioni del sistema perché il completamento del processo di sincronizzazione richiede troppo tempo.
Un altro fattore importante da considerare quando si esegue la migrazione da altri provider di servizi cloud è l'eventuale addebito di costi per l'uscita dei dati. In tal caso potrebbe essere utile valutare la possibilità di ridurre al minimo il footprint fisico dei dati trasferiti. In situazioni come questa la tecnologia di compressione può essere importante per i dump o i flussi di dati usati per la sincronizzazione.
Altri servizi basati su Azure
È possibile che in alcune situazioni si voglia eseguire la migrazione da altri servizi basati su Azure a Database di Azure per PostgreSQL - Server flessibile. Questi database di origine possono trovarsi in macchine virtuali di Azure, contenitori o eventualmente in Database di Azure per PostgreSQL - Server singolo. In tale caso occorre esaminare un insieme di considerazioni diverse ma, allo stesso tempo, si hanno alcune opportunità per trarre vantaggio dalle ottimizzazioni all'interno dei servizi di Azure per questi scenari.
Personalizzazione
L'ultima area da valutare è la quantità di personalizzazione necessaria o desiderata. Questa considerazione può portare alla necessità di modificare la struttura del database di origine per supportare la replica dei dati oppure potrebbe indicare la facilità dell'automatizzazione tramite scripting.
Un buon esempio è automatizzare la migrazione offline di un database tramite pg_dump e pg_restore, ma allo stesso tempo includere la compressione e la decompressione dei file di dump.
Processo decisionale
Dopo avere completato il processo per raccogliere tutte queste informazioni, è possibile collaborare con gli stakeholder per individuare l'opzione migliore per uno scenario specifico. Quando si decide quale metodologia e set di tecnologie usare, è importante collaborare non solo con gli stakeholder in ambito business, ma anche con gli stakeholder tecnici. Questa collaborazione consente di evitare una situazione in cui il business favorisce una migrazione con tempi di inattività minimi, ma il team tecnico non è in grado di fornirla a causa di vincoli di personale, risorse o tecnologie.
L'aspetto fondamentale in questa situazione è gestire le aspettative e avere un dialogo aperto e onesto. È anche importante assicurarsi che il business si assuma la responsabilità delle attività di convalida che non rientrano nelle competenze dei team tecnici che forniscono la migrazione del database. Questa convalida può comportare controlli di coerenza e convalida dei dati e test dell'esperienza utente.