Analizzare i criteri decisionali per la selezione degli strumenti e il modello di migrazione
Ora che sono state esaminate le opzioni per le metodologie di migrazione e le opzioni degli strumenti, è possibile esplorare i criteri decisionali da considerare per eseguire le migrazioni al server flessibile di Database di Azure per PostgreSQL. I tre criteri principali che consentono di scegliere sono Tempo di inattività, Posizione del database di origine e Personalizzazione.
Tempo di inattività
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 o online.
In genere, le attività di migrazione vengono pianificate in anticipo per garantire che i controlli delle modifiche appropriati e la governance associata vengano completati per l'attività. Questa pianificazione consente a un dialogo con gli stakeholder chiave di comprendere per quanto tempo il sistema può essere offline. In questo caso, è consigliabile sapere quanto tempo richiede 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 cut-over dell'applicazione è fondamentale. In definitiva, questo tempo è la quantità di tempo necessaria per rendere offline il sistema, anche per un'attività di migrazione online (o con un tempo di inattività minimo). La complessità dell'applicazione determinerà questa scala cronologica. Per un'applicazione relativamente semplice, questo processo potrebbe essere un caso di 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 in gioco più server e livelli applicazione.
Comprendere la durata necessaria per le attività di migrazione online o offline è l'elemento importante successivo correlato al tempo di inattività. Se si tratta di una migrazione offline, il tempo impiegato per estrarre, trasferire e caricare i dati dall'origine alla destinazione seguita dalla convalida e dalla verifica è il tempo di inattività. 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/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/carico di lavoro.
Dopo avere ottenuto queste informazioni, è possibile esaminare gli elementi tecnici della migrazione per stabilire quali sono le opzioni valide.
Percorso di origine dei database
La posizione di origine dei database da migrare gioca un ruolo a causa dei vincoli che sono probabilmente in atto per una determinata configurazione.
Origini in locale o non di Azure
Per un database locale o non 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 informata sul tipo di migrazione praticabile.
Se si dispone di un volume elevato di dati di cui eseguire la migrazione e una quantità proporzionalmente ridotta di larghezza di banda, un semplice dump e ripristino probabilmente non sarà fattibile. Mentre se si ha un volume elevato di dati e una grande quantità di larghezza di banda, è meno preoccupante.
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 processo di sincronizzazione richiede troppo tempo per il completamento.
Un fattore importante da considerare anche quando si esegue la migrazione da altri provider di servizi cloud è se vengono addebitati costi per l'uscita dei dati. In tal caso, la possibilità di ridurre al minimo il footprint fisico dei dati trasferiti potrebbe essere una considerazione. 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
Ci saranno situazioni in cui si vuole eseguire la migrazione da altri servizi basati su Azure al server flessibile di Database di Azure per PostgreSQL. Questi database di origine possono trovarsi in macchine virtuali di Azure, contenitori o eventualmente nel server singolo di Database di Azure per PostgreSQL. In tal caso, è disponibile un set diverso di considerazioni da esplorare, ma allo stesso tempo, diverse opportunità per trarre vantaggio dalle ottimizzazioni all'interno dei servizi di Azure per questi scenari.
Personalizzazione
L'ultima area di considerazione è la quantità di personalizzazione necessaria o desiderata. Questa considerazione può assumere la forma di necessità di modificare la struttura del database di origine per supportare la replica dei dati, in alternativa, potrebbe significare quanto sia facile automatizzare tramite scripting.
Un buon esempio è automatizzare la migrazione offline di un database tramite pg_dump e pg_restore, ma allo stesso tempo, inclusa la compressione e la decompressione dei file di dump.
Processo decisionale
Ora che è stato eseguito il processo per raccogliere tutte queste informazioni, è possibile collaborare con gli stakeholder per determinare l'opzione migliore per uno scenario specifico. Quando si decide quale metodologia e tecnologia impostare per l'uso, è importante non solo collaborare con gli stakeholder aziendali, ma anche con gli stakeholder tecnici. Questa collaborazione aiuta a evitare una situazione in cui l'azienda punta a una migrazione con downtime minimo, che il team tecnico non è in grado di fornire a causa di vincoli di personale, risorse o tecnologia.
La cosa chiave qui è gestire le aspettative e avere un dialogo aperto e onesto. È anche importante assicurarsi che l'azienda acquisisca la proprietà delle attività di convalida che si trovano al di fuori del compito 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.