Menganalisis kriteria keputusan untuk pemilihan alat dan model migrasi
Sekarang setelah kita menjelajahi opsi untuk metodologi migrasi dan opsi alat, kita dapat menjelajahi kriteria keputusan yang perlu kita pertimbangkan untuk menjalankan migrasi kita ke Azure Database for PostgreSQL Flexible Server. Tiga kriteria utama yang membantu kami membuat pilihan adalah Waktu Henti, Lokasi database sumber, dan Penyesuaian.
Waktu henti
Waktu henti adalah aspek utama aktivitas migrasi dan durasi yang dapat diterima oleh pemangku kepentingan membantu kami memutuskan apakah kami harus melakukan aktivitas migrasi offline atau online.
Biasanya, aktivitas migrasi direncanakan dengan baik terlebih dahulu untuk memastikan bahwa kontrol perubahan yang sesuai dan tata kelola terkait selesai untuk aktivitas tersebut. Perencanaan ini memungkinkan dialog dengan pemangku kepentingan utama untuk memahami berapa lama sistem dapat offline. Dalam situasi ini, disarankan untuk mengetahui berapa lama waktu yang dibutuhkan untuk berbagai opsi, Anda dapat menetapkan perkiraan durasi waktu henti minimum dan maksimum.
Menetapkan waktu henti minimum yang diperlukan untuk melakukan cut-over aplikasi adalah kuncinya. Pada akhirnya, kali ini adalah jumlah yang Anda miliki untuk membuat sistem offline bahkan untuk aktivitas migrasi online (atau waktu henti minimal). Kompleksitas aplikasi akan menentukan skala waktu ini. Untuk aplikasi yang relatif sederhana, proses ini bisa menjadi kasus menghentikan layanan, memperbarui file konfigurasi, lalu mengaktifkannya kembali. Di lingkungan yang lebih kompleks, proses ini dapat memakan waktu lebih lama jika ada beberapa server dan lapisan aplikasi yang sedang dimainkan.
Memahami durasi yang diperlukan untuk aktivitas migrasi online atau offline adalah elemen penting berikutnya yang terkait dengan waktu henti. Jika ini adalah migrasi offline, waktu yang diperlukan untuk mengekstrak, mentransfer, dan memuat data dari sumber ke tujuan diikuti dengan validasi dan verifikasi adalah waktu henti Anda. Waktu henti ini kemudian diapit antara waktu yang diperlukan untuk mematikan aplikasi/beban kerja dan waktu yang diperlukan untuk mengaktifkan kembali aplikasi/beban kerja.
Jika ini adalah migrasi online (waktu henti minimal), waktu henti adalah durasi yang diperlukan untuk menyinkronkan perubahan akhir dari sumber ke tujuan setelah aplikasi dinonaktifkan. Tambahkan ke waktu henti, validasi, dan aktivitas verifikasi sebelum kemudian mengonfigurasi ulang dan mengaktifkan aplikasi/beban kerja.
Setelah kami memiliki informasi ini, kita dapat melihat elemen teknis migrasi untuk membantu menetapkan opsi yang layak.
Lokasi database sumber
Lokasi sumber database yang akan dimigrasikan memainkan peran karena kendala yang kemungkinan akan diberlakukan untuk konfigurasi tertentu.
Sumber lokal atau non-Azure
Untuk database lokal atau non-Azure yang terletak, batasan utama biasanya adalah konektivitas jaringan antara sumber dan target. Tiga poin yang perlu dipertimbangkan di sini adalah bandwidth, latensi, dan volume data. Setelah memahami poin-poin ini, kita dapat membuat keputusan berdasarkan informasi tentang jenis migrasi mana yang layak.
Jika kita memiliki data dalam jumlah besar untuk dimigrasikan dan jumlah bandwidth yang proporsional kecil, maka cadangan dan pemulihan sederhana mungkin tidak akan layak. Sedangkan jika kita memiliki data dalam jumlah besar dan sejumlah besar bandwidth, maka itu kurang menjadi perhatian.
Demikian juga, jika ini adalah migrasi online di mana sinkronisasi data akan terjadi maka latensi adalah salah satu faktor utama. Jika latensi tinggi, mungkin ada dampak buruk pada performa sistem karena proses sinkronisasi membutuhkan waktu yang terlalu lama untuk diselesaikan.
Salah satu faktor penting yang juga perlu dipertimbangkan saat bermigrasi dari penyedia cloud lainnya adalah apakah mereka mengenakan biaya untuk keluarnya data. Jika demikian, maka dapat meminimalkan jejak fisik data yang ditransfer bisa menjadi pertimbangan. Dalam situasi seperti ini, teknologi kompresi bisa menjadi penting untuk cadangan atau aliran data yang digunakan untuk sinkronisasi.
Layanan berbasis Azure lainnya
Akan ada situasi di mana Anda ingin bermigrasi dari layanan berbasis Azure lainnya ke Azure Database for PostgreSQL Flexible Server. Database sumber ini dapat berada di Azure VM, kontainer, atau mungkin Azure Database for PostgreSQL Single Server. Jika demikian, maka ada serangkaian pertimbangan yang berbeda untuk dijelajahi tetapi pada saat yang sama, beberapa peluang untuk mendapatkan manfaat dari pengoptimalan dalam layanan Azure untuk skenario ini.
Penyesuaian
Area akhir pertimbangan adalah berapa banyak penyesuaian yang diperlukan atau diinginkan. Pertimbangan ini dapat berupa kebutuhan untuk memodifikasi struktur database sumber untuk mendukung replikasi data, atau, itu bisa berarti betapa mudahnya Bagi Anda untuk mengotomatiskan melalui pembuatan skrip.
Contoh yang baik adalah mengotomatiskan migrasi offline database melalui pg_dump dan pg_restore tetapi pada saat yang sama termasuk kompresi dan dekompresi file cadangan.
Pengambilan keputusan
Sekarang setelah kami melalui proses untuk mengumpulkan semua informasi ini, kami dapat bekerja dengan pemangku kepentingan untuk menentukan opsi terbaik untuk skenario tertentu. Ketika membuat keputusan tentang metodologi dan teknologi mana yang ditetapkan untuk digunakan, penting untuk tidak hanya bekerja dengan pemangku kepentingan bisnis, tetapi juga pemangku kepentingan teknis. Kolaborasi ini membantu menghindari situasi di mana bisnis mendorong migrasi waktu henti minimal, yang tidak dihadirkan oleh tim teknis karena kendala staf, sumber daya, atau teknologi.
Hal utama di sini adalah mengelola harapan dan memiliki dialog yang terbuka dan jujur. Penting juga untuk memastikan bahwa bisnis mengambil kepemilikan tugas validasi yang berada di luar pengiriman tim teknis yang mengirimkan migrasi database. Validasi ini dapat melibatkan konsistensi data dan pemeriksaan validasi, dan pengujian pengalaman pengguna.