Dokumen ini menjelaskan praktik terbaik untuk migrasi Db2 homogen ke Compute Engine. Dokumen ini ditujukan bagi admin database, admin sistem dan software, database, serta engineer operasi yang memigrasikan lingkungan Db2 ke Google Cloud. Migrasi dari Db2 ke jenis database lain berada di luar cakupan dokumen ini.
Terminologi
- IBM Db2
- Sistem manajemen database relasional (RDBMS) tingkat perusahaan, dengan kemampuan replikasi dan failover.
- Pemulihan bencana ketersediaan tinggi (HADR)
- Kemampuan untuk Db2 yang menggunakan aktivitas yang dicatat ke dalam database untuk mereplikasi data dari database utama ke standby. Fitur ini memungkinkan failover manual dari database utama ke database standby.
- Kasus penggunaan
- Mesin yang menghosting Db2 yang menerima permintaan tulis serta baca. Mesin ini adalah sumber replikasi ke mesin standby
- Standby Utama
- Mesin standby yang hanya dapat menerima permintaan baca. Mesin ini mendukung semua mode sinkronisasi yang diizinkan oleh Db2 dan dirancang sebagai instance failback untuk tujuan HADR. IBM Db2 hanya mengizinkan satu mesin tersebut dalam cluster.
- Standby tambahan
- Mesin standby yang hanya dapat menerima permintaan baca. Mesin ini hanya mendukung mode sinkronisasi SUPERASYNC dan berada di pusat data yang berbeda dengan mesin utama jika terjadi failover manual jika pusat data utama gagal.
- Otomatisasi Sistem Tivoli untuk Multiplatform (TSA/MP)
- Software pengelolaan cluster yang memfasilitasi failover resource otomatis dari database utama ke standby utama. Software ini mencakup resource jaringan, penyimpanan, dan komputasi yang ditentukan sebagai bagian dari cluster. Edisi perusahaan Db2 dilengkapi dengan hak TSAMP untuk HADR yang disertakan.
- Pengalihan klien otomatis (ACR)
- Fitur Db2 yang mengalihkan aplikasi klien dari server yang gagal ke server alternatif sehingga aplikasi dapat terus berfungsi dengan sedikit gangguan.
- Pengambilan data perubahan (CDC)
- Serangkaian teknik atau alat untuk mendeteksi perubahan dalam database, seperti sinkronisasi data dengan database lain atau membuat jejak audit.
Arsitektur
Cluster Db2 biasanya terdiri dari setidaknya node standby primer dan utama dengan HADR di antara keduanya. Pada versi Db2 yang lebih baru, Anda juga dapat menambahkan node standby tambahan yang berfungsi untuk tujuan DR.
Diagram berikut menggambarkan lingkungan sumber.
Dalam lingkungan ini, standby primer dan utama berada di satu pusat data dan standby tambahan berada di pusat data yang berbeda.
Tujuan migrasi adalah untuk membuat ulang lingkungan ini di Google Cloud seperti yang ditunjukkan pada diagram berikut.
Tabel berikut membandingkan aspek dari setiap jenis migrasi.
| Migrate to Virtual Machines | Replikasi Q | Replikasi SQL | HADR | |
|---|---|---|---|---|
| Sumber | VM VMware, Amazon Web Services (AWS) | Lingkungan Db2 apa pun, berdasarkan lisensi | Lingkungan Db2 apa pun | Lingkungan Db2 apa pun |
| Apa yang direplikasi? | Replikasi disk tingkat blok | Tabel dalam database | Tabel dalam database | Seluruh database |
| Migrasi sistem | Memerlukan beberapa menit agar VM diluncurkan di Google Cloud | Arahkan aplikasi dan DNS ke instance Compute Engine | Arahkan aplikasi dan DNS ke instance cloud | Arahkan aplikasi dan DNS ke instance cloud |
| Replikasi perubahan DDL | Ya (penulisan disk yang sedang direplikasi) | Ya | Ya | Ya |
| Replikasi data sinkron | T/A | Tidak | Ya | Ya |
| Replikasi data asinkron | T/A | Ya | Ya | Ya |
| Replikasi data point-in-time | Tidak | Ya | Ya | Tidak |
Tabel sebelumnya adalah panduan untuk membantu Anda mencocokkan persyaratan ketersediaan sistem dan tingkat upaya resource untuk menyiapkan sistem target, menyiapkan replikasi, serta mempertahankan dan menguji replikasi dari waktu ke waktu. Tabel ini menunjukkan bahwa Migrasi to VMs adalah pendekatan yang paling mudah untuk diimplementasikan, tetapi paling tidak fleksibel dalam hal ketersediaan sistem. Atau, HADR, replikasi Q, dan Replikasi SQL memiliki dampak yang lebih rendah terhadap ketersediaan sistem sebagai ganti atas tingkat upaya yang lebih tinggi untuk menyiapkan dan mempertahankan replikasi dalam model paralel.
Jenis migrasi
Ada dua cara untuk memigrasikan Db2 ke Compute Engine:
- Migrasi yang melibatkan modifikasi konfigurasi cluster atau topologi yang ada.
- Migrasi yang mereplikasi data ke dalam cluster yang benar-benar baru.
Mengubah cluster yang sudah ada tidak memerlukan peluncuran cluster yang benar-benar baru di cloud, dan oleh karena itu, dapat lebih cepat. Cara lain untuk melakukan migrasi mengharuskan Anda men-deploy cluster baru ke Google Cloud, tetapi berdampak lebih kecil pada cluster yang ada karena replikasinya out-of-band. Metode ini juga berguna jika Anda hanya ingin mereplikasi sebagian database atau melakukan transformasi pada data sebelum sampai di target.
Bagian berikut membahas hal-hal yang harus dipertimbangkan sebelum memindahkan instance Db2 ke Google Cloud. Beberapa kemampuan yang umum digunakan mungkin tidak berfungsi apa adanya di Google Cloud atau mungkin memerlukan beberapa perubahan konfigurasi.
Alamat IP mengambang (virtual)
Pada cluster Db2 yang sangat tersedia, TSA/MP dapat menetapkan alamat IP virtual ke node utama. Alamat ini juga disebut alamat IP mengambang dan berarti bahwa traffic selalu dirutekan ke node utama, bukan ke standby.
Compute Engine menggunakan stack jaringan virtual di jaringan Virtual Private Cloud (VPC) sehingga mekanisme implementasi standar mungkin tidak berfungsi. Misalnya, jaringan VPC menangani permintaan Address Resolution Protocol (ARP) berdasarkan topologi perutean yang dikonfigurasi, dan mengabaikan frame ARP yang serampangan. Selain itu, tabel perutean jaringan VPC tidak dapat langsung diubah dengan protokol perutean standar seperti Open Shortest Path First Protocol (OSPF) atau Border Gateway Protocol (BGP). Oleh karena itu, Anda harus menerapkan alternatif untuk alamat IP mengambang atau menggunakan ACR.
Jika Anda memindahkan beberapa atau semua node dalam cluster Db2, pastikan untuk menonaktifkan alamat IP mengambang untuk cluster Anda sebelum memindahkan node mana pun.
ACR
Jika lingkungan Db2 Anda menggunakan ACR , Anda mungkin perlu mengubah katalog pada klien Anda jika nama DNS berubah atau jika klien Anda terhubung dengan menggunakan alamat IP.
Tiebreaker
TSA/MP mengharuskan sebagian besar node cluster online untuk memulai tindakan otomatisasi. Jika cluster terdiri dari jumlah node genap, ada kemungkinan setengah dari node cluster online, dan ada kemungkinan terjadinya skenario split-brain. Dalam hal ini, TSA/MP menggunakan tiebreaker untuk menentukan status quorum (kelompok mayoritas), yang menentukan apakah tindakan otomatisasi dapat dimulai.
Pertimbangkan tiebreaker berikut yang mungkin digunakan oleh lingkungan Db2 Anda:
- Tiebreaker penyimpanan atau disk. Ibm Db2 menggunakan pemesanan disk untuk memutus hubungan. Karena reservasi tidak tersedia di Google Cloud, Anda harus memilih jenis tiebreaker yang berbeda.
- Tiebreaker jaringan. Menggunakan alamat IP eksternal (ke cluster) untuk menyelesaikan situasi terikat. Dalam deployment hybrid, tiebreaker jaringan Anda mungkin tidak perlu dialihkan ke Google Cloud pada awalnya selama dapat dijangkau dari node cluster. Namun, setelah cluster berjalan di Google Cloud, praktik yang baik adalah membuat tiebreaker di zona berbeda atau menggunakan server metadata Google Cloud sebagai tiebreaker.
- Tiebreaker NFS. Tiebreaker NFS menyelesaikan situasi ikatan yang didasarkan pada file cadangan yang disimpan di server NFS v4. Seperti halnya tiebreaker jaringan, tiebreaker NFS dan server NFS v4 juga dapat tetap berada di lokasi aslinya dalam deployment hybrid. Nantinya, praktik yang lebih baik adalah men-deploy server NFS Anda sendiri atau menggunakan partner seperti Elastifile sebagai target tiebreaker NFS di Google Cloud.
Bermigrasi menggunakan Migrate to VMs
Jika kedua hal berikut ini berlaku untuk lingkungan Anda, Migrate to VMs adalah opsi yang direkomendasikan:
Anda memiliki lingkungan VMware vCenter atau mesin virtual di Amazon Elastic Compute Cloud (Amazon EC2).
Anda memiliki koneksi pribadi dari Google Cloud ke lingkungan Anda, seperti Cloud VPN atau Cloud Interconnect.
Migrate to VMs digunakan untuk memigrasikan mesin virtual dari lingkungan lokal dan cloud ke Google Cloud. Dengan fitur ini, Anda dapat memigrasikan mesin virtual ke Google Cloud dalam beberapa menit, sementara data disalin di latar belakang, tetapi mesin virtual tetap beroperasi sepenuhnya. Anda harus memiliki koneksi pribadi antara lingkungan sumber ke project Google Cloud, seperti Cloud VPN, Cloud Interconnect, atau Partner Interconnect.
Dengan Migrasi to VMs, Anda harus mengevaluasi ulang konfigurasi database di VM cloud. Beberapa konfigurasi mungkin tidak dioptimalkan untuk Google Cloud, seperti variabel registry, kumpulan buffer, konfigurasi database manager
atau
konfigurasi database.
Anda dapat menggunakan utilitas
AUTOCONFIGURE
untuk memulai dari dasar pengukuran.
Metodologi operasional Migrasi to VMs dijelaskan secara terperinci dalam siklus proses migrasi VM.
Bagian berikut menguraikan cara menerapkan metodologi ini untuk lingkungan Db2.
Clone uji
clone pengujian hanya tersedia di lingkungan vCenter.
Migrasi to VMs dapat mengambil snapshot VM Anda dan membuat instance komputasi yang siap digunakan di Google Cloud berdasarkan snapshot tersebut. Anda dapat membuat ulang lingkungan Db2 di Google Cloud, mencoba perubahan konfigurasi, menguji, dan melakukan tolak ukur deployment tanpa konsekuensi terhadap lingkungan sumber Anda.
Diagram berikut menunjukkan lingkungan DB2 Anda di Google Cloud dengan lingkungan berdampingan di Google Cloud setelah cloning pengujian Migrate to VMs.
Setelah menjalankan benchmark dan menguji clone pengujian di Google Cloud, Anda dapat menghapus clone pengujian tersebut.
Jalankan di cloud
Saat mengaktifkan run-in-cloud, Migrate to VMs akan menonaktifkan cluster sumber dan memulai VM di Google Cloud, sekaligus mengambil data sesuai kebutuhan saja dan tidak mengalirkan seluruh penyimpanan ke Google Cloud. Run-in-cloud mendukung penulisan kembali dan diaktifkan secara default. Migrasi to VMs membantu Anda menguji lingkungan sebelum melakukan streaming penyimpanan secara aktif. Anda juga dapat memindahkan VM kembali ke lingkungan sumber menggunakan fitur move back. Dalam migrasi cloud ke cloud, Anda tidak dapat mereplikasi penulisan kembali ke sumber.
Diagram berikut menunjukkan fase run-in-cloud, jika Anda menetapkan semua node untuk dijalankan di cloud. Anda dapat memutuskan untuk memindahkan node cluster secara bertahap, bukan seluruh cluster sekaligus.
Migrasi
Fase migrasi mirip dengan fase run-in-cloud, tetapi Migrate to VMs juga secara aktif mengalirkan penyimpanan ke Google Cloud. Selama fase run-in-cloud, Migrate to VMs hanya menghadirkan data sesuai permintaan untuk menghemat bandwidth karena Anda belum menyatakan bahwa Anda siap memindahkan VM sepenuhnya.
Lepaskan
Selama fase ini, Migrate to VMs menyinkronkan data dari cache dan penyimpanan objek ke disk data native di Google Cloud, lalu memasang disk ke VM. Fase ini mengharuskan Anda menonaktifkan VM di Google Cloud. Untuk Db2, sebaiknya lepaskan satu node cluster dalam satu waktu.
Menggunakan replikasi
Untuk Db2, replikasi adalah proses merekam perubahan dari log transaksi menggunakan program yang disebut program capture, lalu menerapkannya ke cluster yang berbeda menggunakan program apply. Cara program capture menangkap perubahan dan jenis saluran komunikasi yang digunakan untuk mengirimkan perubahan ke program apply akan berbeda untuk setiap jenis replikasi.
Diagram berikut menunjukkan aliran informasi yang logis dalam replikasi Db2.
Aplikasi pengambilan merekam perubahan dari database dan mengirimkan perubahan tersebut ke aplikasi yang diterapkan. Aplikasi yang menerapkan akan menulis perubahan tersebut ke database target. Ada beberapa transformasi yang dapat dilakukan aplikasi pada data itu sendiri. Aplikasi pengambilan dan penerapan tidak perlu berjalan di server database itu sendiri.
Replikasi SQL
Replikasi SQL menangkap perubahan pada tampilan dan tabel sumber, serta menggunakan tabel staging untuk menyimpan data transaksional yang di-commit. Perubahan tersebut kemudian dibaca dari tabel staging dan direplikasi ke tabel target yang sesuai. Pada saat menulis dokumen ini, saat Anda menginstal Db2, Replikasi SQL tersedia untuk Anda.
Proses migrasi yang memanfaatkan Replikasi SQL akan terlihat seperti ini:
- Men-deploy Db2 di Google Cloud.
- Mengonfigurasi Replikasi SQL.
- Mulai Replikasi SQL.
- Pastikan deployment sudah sinkron.
- Arahkan aplikasi Anda ke instance Google Cloud. Hentikan replikasi.
Diagram berikut adalah contoh replikasi SQL.
Lingkungan produksi Anda berfungsi seperti biasa, sambil mereplikasi perintah SQL ke cluster baru yang Anda buat di Google Cloud. Pada diagram sebelumnya, proses replikasi berjalan pada instance utama, tetapi ada berbagai cara untuk men-deploy-nya yang berada di luar cakupan dokumen ini.
Replikasi Q
Replikasi Q adalah cara yang lebih baru dan lebih efisien daripada Replikasi SQL untuk mereplikasi data dari satu instance Db2 ke instance Db2 lainnya. Metode ini menggunakan IBM MQ untuk mengirimkan entri perubahan data, yang berarti Anda harus men-deploy instance IBM MQ di lingkungan sumber dan lingkungan target. Metode replikasi ini lebih cepat daripada replikasi SQL karena berada dalam memori. Replikasi SQL lebih lambat, tetapi replikasi Q biasanya lebih sulit disiapkan karena Anda perlu menyiapkan IBM MQ. Bergantung pada lisensi Db2, Anda mungkin harus mendapatkan lisensi untuk replikasi Q.
Saat memulai replikasi Db2 Q, Anda dapat memilih di antara dua metode berikut:
Pemuatan otomatis. Proses replikasi Q melakukan pemuatan awal, yang berarti memulihkan database target dari cadangan sumber.
Pemuatan manual. Lakukan pemuatan awal, lalu mulai replikasi dari titik di log.
Proses migrasi terlihat seperti ini:
- Deploy IBM MQ di Google Cloud dan di lingkungan sumber Anda.
- Men-deploy Db2 di Google Cloud.
- Mengonfigurasi replikasi Q.
- Mulai replikasi Q (baik dengan pemuatan manual atau pemuatan otomatis).
- Pastikan kedua deployment sudah sinkron.
- Arahkan aplikasi Anda ke instance Google Cloud. Hentikan replikasi.
Diagram berikut menunjukkan kemungkinan solusi replikasi Q.
Lingkungan sumber menggunakan replikasi IBM Q untuk mengirim perubahan database ke IBM MQ dan lingkungan target, yang memperluas cluster Db2 ke Compute Engine
Dengan pendekatan ini, Anda secara bertahap memindahkan cluster Db2 yang ada ke Compute Engine dan mengandalkan HADR untuk transfer data antar-node.
Gunakan pendekatan ini jika Anda memenuhi kondisi berikut:
- Anda tidak ingin men-deploy cluster yang benar-benar baru di Compute Engine.
- Anda tidak dapat memanfaatkan Migrate to VMs.
- Anda tidak dapat menggunakan salah satu opsi replikasi.
- Anda tidak boleh atau tidak dapat menggunakan produk partner (dengan beberapa alasan seperti pemberian lisensi, biaya, atau kepatuhan).
Jika versi Db2 Anda tidak mendukung mode standby tambahan
Anda dapat melakukan hal berikut:
- Deploy instance Db2 di Compute Engine.
- Ambil cadangan dari instance utama Anda.
- Pulihkan instance Db2 di Compute Engine dari cadangan.
- Hapus instance standby dari penyiapan HADR.
- Instal instance Db2 Compute Engine sebagai standby (Anda dapat memilih mode sinkronisasi, tetapi karena kemungkinan latensi yang lebih tinggi ,
ASYNCatauNEARASYNCmungkin lebih disukai). - Failover ke instance Db2 Compute Engine dan jadikan sebagai HADR primer.
- Buat instance Db2 Compute Engine lain, pulihkan dari cadangan, dan siapkan sebagai mode HADR standby.
Langkah pertama dalam diagram berikut menunjukkan instance Db2 yang baru dibuat di Google Cloud yang disiapkan sebagai standby utama dari sumber utama Db2.
Pada diagram sebelumnya, instance Google Cloud menjadi HADR primer. Kemudian, Anda menghapus standby utama sumber dan menambahkan instance Db2 lain di Compute Engine sebagai instance standby utama.
Jika versi Db2 Anda mendukung mode standby tambahan
Salah satu opsinya adalah mengikuti langkah-langkah yang sama seperti saat versi Db2 tidak mendukung mode standby tambahan, dan di akhir proses, pindahkan juga instance standby tambahan.
Opsi lainnya adalah memanfaatkan replika tambahan untuk migrasi yang lebih fault-tolerant ke Google Cloud, karena Anda tidak memiliki standby primer atau utama di lingkungan sumber Anda dan yang lainnya di Google Cloud. Daftar berikut menguraikan langkah-langkah untuk opsi kedua ini:
- Deploy instance Db2 di Compute Engine (primer, utama, tambahan jika diperlukan) ke lokasinya.
- Hapus node standby tambahan dari cluster sumber.
- Konfigurasikan node yang akan menjadi node primer dan utama standby tambahan cluster sumber.
- Melakukan pengambilalihan salah satu instance Compute Engine. Instance ini menjadi instance utama.Konfigurasikan salah satu instance Compute Engine lainnya sebagai mode standby utama dari instance utama.
Langkah pertama yang digambarkan dalam diagram berikut menunjukkan dua instance Db2 yang baru dibuat di Compute Engine.
Instance disiapkan sebagai standby tambahan untuk instance utama Db2 sumber, bukan instance tambahan di lingkungan sumber. Kemudian, setelah memanggil pengambilalihan ke salah satu instance Compute Engine, instance tersebut menjadi HADR utama dan satu instance lainnya dikonfigurasi sebagai mode standby utama. Pada langkah terakhir, dua instance lainnya dikonfigurasi sebagai mode standby tambahan.
Produk Partner
Google memiliki beberapa partner yang memiliki produk untuk membantu migrasi tersebut. Sebagian besar produk ini memanfaatkan CDC untuk mereplikasi data antara sumber Db2 dan target. Produk ini bukan merupakan produk Google Cloud, dan Anda perlu memeriksa pemberian lisensi dan harga untuk setiap produk atau layanan. Biasanya, layanan ini mereplikasi data dari cluster yang ada ke cluster lain yang Anda buat di Google Cloud, dan pendekatannya secara keseluruhan mirip dengan skenario replikasi yang dijelaskan dalam dokumen ini.
Berikut adalah beberapa produk partner:
Langkah selanjutnya
- Panduan perencanaan IBM Db2 untuk SAP.
- Pusat migrasi database Google Cloud.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.