Menjelajahi migrasi database yang sangat besar
Sistem SAP yang pindah ke cloud Azure sekarang umumnya mencakup sistem "instans global tunggal" multinasional besar. Sistem ini berkali-kali lebih besar dari sistem pelanggan pertama yang digunakan ketika platform Azure pertama kali disertifikasi untuk beban kerja SAP.
Very Large Database (VLDB) sekarang biasanya dipindahkan ke Azure. Ukuran database yang lebih dari 20 TB memerlukan beberapa teknik dan prosedur tambahan untuk mencapai migrasi dari lokal ke Azure dalam waktu henti yang dapat diterima dan risiko rendah.
Ringkasan tingkat tinggi
Migrasi basis data yang sangat besar yang dioptimalkan sepenuhnya harus mencapai sekitar 2 TB per jam throughput migrasi per jam atau mungkin lebih. Ini berarti komponen transfer data dari migrasi 20 TB dapat dilakukan dalam waktu sekitar 10 jam. Berbagai langkah pascaproses dan validasi perlu dilakukan. Secara umum, dengan waktu yang cukup untuk persiapan dan pengujian, sistem pelanggan apa pun dengan ukuran apa pun dapat dipindahkan ke Azure.
Migrasi VLDB membutuhkan kemampuan, perhatian terhadap detail, dan analisis yang cukup besar. Misalnya, efek bersih dari pembagian tabel harus diukur dan dianalisis. Perpecahan tabel besar menjadi lebih dari 50 ekspor paralel dapat sangat mengurangi waktu yang dibutuhkan untuk mengekspor tabel, tetapi terlalu banyak pembagian tabel dapat mengakibatkan waktu impor meningkat secara drastis. Oleh karena itu efek bersih dari pembagian tabel harus dihitung dan diuji. Konsultan migrasi OS/DB berlisensi ahli akan terbiasa dengan konsep dan alat. Kami menyoroti beberapa konten khusus Azure untuk migrasi VLDB.
Secara khusus, kami menangani migrasi OS/DB heterogen ke Azure dengan SQL Server sebagai database target menggunakan alat seperti R3load dan Migmon. Langkah-langkah migrasi tidak ditujukan untuk salinan sistem homogen, salinan tempat DBMS dan arsitektur prosesor (Endian Order) tetap sama. Secara umum, Salinan Sistem Homogen harus memiliki waktu henti yang rendah terlepas dari ukuran DBMS karena pengiriman log dapat digunakan untuk menyinkronkan salinan database di Azure.
Diagram blok yang diilustrasikan dari migrasi OS/DB VLDB umum dan pindah ke Azure mengikuti setelah poin-poin utama:
Sumber OS/DB saat ini sering kali berupa AIX, HPUX, Solaris, atau Linux; dan DB2 atau Oracle.
OS target adalah Windows, Suse 12.3, Redhat 7.x, atau Oracle Linux 7.x.
Target DB biasanya berupa SQL Server atau Oracle 12.2.
IBM pSeries, perangkat keras SPARC Solaris, dan performa rangkaian HP Superdome secara drastis lebih rendah daripada server komoditas Intel modern berbiaya rendah, oleh karena itu R3load dijalankan pada server Intel terpisah.
VMWare memerlukan penyetelan dan konfigurasi khusus untuk mencapai performa jaringan yang baik, stabil, dan dapat diprediksi. Biasanya, server fisik digunakan sebagai server R3load dan bukan VM.
Umumnya empat server R3load ekspor digunakan, meskipun tidak ada batasan jumlah server ekspor. Konfigurasi umum adalah:
- Server ekspor 1 - khusus untuk tabel 1-4 terbesar (tergantung pada seberapa condong distribusi data pada database sumber)
- Server ekspor 2 - khusus untuk tabel dengan pemisahan tabel
- Server ekspor 3 - khusus untuk tabel dengan pemisahan tabel
- Server ekspor 4 – semua tabel yang tersisa
File cadangan ekspor ditransfer dari disk lokal di server R3load berbasis Intel ke Azure menggunakan AzCopy melalui internet publik. Ini biasanya lebih cepat daripada melalui ExpressRoute.
Kontrol dan urutan impor melalui file sinyal (SGN) yang secara otomatis dihasilkan ketika semua paket ekspor selesai. Hal ini memungkinkan untuk ekspor/impor semi-paralel.
Mengimpor ke SQL Server atau Oracle memiliki struktur yang mirip dengan ekspor, memanfaatkan empat server impor. Server ini akan menjadi server R3load khusus terpisah dengan Jaringan Dipercepat. Disarankan untuk tidak menggunakan server aplikasi SAP untuk tugas ini.
Database VLDB biasanya akan menggunakan VM E64v3, m64, atau m128 dengan Penyimpanan Premium. Log Transaksi dapat ditempatkan pada SSD lokal untuk mempercepat penulisan Log Transaksi dan menghapus IOPS Log Transaksi dan bandwidth IO dari kuota VM. Setelah migrasi, log transaksi harus ditempatkan pada disk yang bertahan.
