Memeriksa praktik terbaik migrasi database yang sangat besar

  • 11 menit

Pedoman berikut yang terkandung didasarkan pada proyek pelanggan nyata dan pembelajaran yang berasal dari proyek-proyek ini. Pedoman mengidentifikasi skenario yang tidak berhasil di masa lalu. Contohnya adalah rekomendasi untuk tidak menggunakan server UNIX atau server virtual sebagai server ekspor R3load:

  • Sering kali, performa ekspor adalah faktor penentu pada waktu henti secara keseluruhan. Sering kali perangkat keras saat ini berusia lebih dari 4-5 tahun dan sangat mahal untuk ditingkatkan.
  • Oleh karena itu penting untuk mendapatkan performa ekspor maksimum yang praktis untuk dicapai.
  • Proyek-proyek sebelumnya telah menghabiskan berminggu-minggu atau bahkan berbulan-bulan mencoba untuk menyetel performa ekspor R3load pada platform UNIX atau virtual, sebelum menyerah dan menggunakan server R3load Intel.
  • Server Intel komoditas dual-soket tidak mahal dan memberikan perolehan performa yang substansial, dalam beberapa kasus urutan besarnya lebih besar dari peningkatan penyetelan kecil yang mungkin terjadi di UNIX atau server virtual.
  • Pelanggan sering memiliki farm VM yang ada tetapi paling sering ini tidak mendukung teknologi offload modern atau SR-IOV. Seringkali versi VMware sudah lama, tidak dipatch, atau tidak dikonfigurasi untuk throughput jaringan tinggi dan latensi rendah. Server ekspor R3load membutuhkan kinerja rangkaian yang sangat cepat dan throughput jaringan yang sangat tinggi. Server ekspor R3load dapat berjalan selama 10-15 jam dengan hampir 100% CPU dan pemanfaatan jaringan. Ini bukan kasus penggunaan umum dari sebagian besar farm VMware dan sebagian besar penyebaran VMware tidak pernah dirancang untuk menangani beban kerja seperti R3load.

Tip

Jangan menginvestasikan waktu untuk mengoptimalkan performa ekspor R3load pada platform UNIX atau virtual. Melakukan hal itu tidak hanya akan membuang waktu tetapi akan lebih mahal daripada membeli server Intel berbiaya rendah pada awal proyek. Oleh karena itu, pelanggan migrasi VLDB diminta untuk memastikan tim proyek memiliki server ekspor R3load modern yang cepat yang tersedia pada awal proyek. Ini akan menurunkan total biaya dan risiko proyek.

Praktik Terbaik

  • Survei dan inventaris lanskap SAP saat ini. Identifikasi tingkat Paket Dukungan SAP dan tentukan apakah patching diperlukan untuk mendukung DBMS target. Secara umum, kompatibilitas sistem operasi ditentukan oleh kernel SAP dan kompatibilitas DBMS ditentukan oleh tingkat patch SAP_BASIS.
  • Buat daftar Sap OSS Notes yang perlu diterapkan dalam sistem sumber, seperti pembaruan untuk SMIGR_CREATE_DDL. Pertimbangkan untuk meningkatkan kernel SAP di sistem sumber untuk menghindari perubahan besar selama migrasi ke Azure (misalnya. Jika sistem menjalankan kernel 7.41 lama, perbarui ke 7.45 terbaru pada sistem sumber untuk menghindari perubahan besar selama migrasi).
  • Mengembangkan dan mendokumentasikan ketersediaan tinggi dan solusi pemulihan bencana. Dokumentasi harus memecah solusi menjadi lapisan DB, lapisan ASCS, dan lapisan server aplikasi SAP. Solusi terpisah mungkin diperlukan untuk solusi mandiri seperti TREX atau liveCache.
  • Kembangkan dokumen ukuran dan konfigurasi yang merinci jenis dan konfigurasi penyimpanan VM Azure. Berapa banyak disk premium, berapa banyak datafiles, bagaimana datafiles didistribusikan di seluruh disk, penggunaan ruang penyimpanan, ukuran format NTFS = 64 kb. Juga, pencadangan/pemulihan dokumen dan konfigurasi DBMS seperti pengaturan memori, tingkat maks paralelisme, dan traceflags.
  • Kembangkan dokumen desain jaringan termasuk VNet, Subnet, NSG dan konfigurasi UDR.
  • Dokumentasikan dan terapkan konsep keamanan dan pengerasan. Hapus Internet Explorer, buat kontainer Azure Active Directory untuk akun dan server layanan SAP, dan terapkan kebijakan firewall yang memblokir semua kecuali sejumlah port yang diperlukan.
  • Buat dokumen desain migrasi OS/DB yang merinci konsep pemisahan paket dan tabel, jumlah R3loads, traceflags SQL Server, diurutkan/tanpa sortir, pengaturan Oracle RowID, pengaturan SMIGR_CREATE_DDL, penghitung Perfmon (seperti BCP baris/detik dan throughput BCP kb/detik, CPU, memori), pengaturan RSS, pengaturan Jaringan Dipercepat, konfigurasi file log, pengaturan BPE, konfigurasi TDE.
  • Buat grafik "Rencana Penerbangan" yang menunjukkan kemajuan ekspor/impor R3load pada setiap siklus uji. Hal ini memungkinkan tim migrasi untuk memvalidasi apakah penyetelan dan perubahan meningkatkan performa ekspor atau impor R3load. Sumbu X adalah jumlah paket selesai, dan sumbu Y adalah waktu yang berlalu. Rencana penerbangan ini juga penting selama migrasi produksi sehingga kemajuan yang direncanakan dapat dibandingkan dengan kemajuan aktual dan masalah apa pun yang diidentifikasi lebih awal.
  • Buat rencana pengujian kinerja. Identifikasi ~20 laporan online teratas, tugas batch, dan antarmuka. Dokumentasikan parameter input (seperti rentang tanggal, kantor penjualan, pabrik, kode perusahaan, dll.) dan runtime pada sistem sumber asli. Bandingkan dengan runtime di Azure. Jika ada perbedaan performa, jalankan SAT, ST05, dan alat SAP lainnya untuk mengidentifikasi pernyataan yang tidak efisien.
  • Audit penyebaran dan konfigurasi, dan pastikan bahwa batas waktu kluster, kernel, pengaturan jaringan, ukuran format NTFS semuanya konsisten dengan dokumen desain. Atur penghitung perfmon di server penting untuk merekam parameter kesehatan dasar setiap 90 detik. Verifikasi bahwa server SAP berada dalam wadah AD terpisah dan bahwa kontainer memiliki kebijakan grup yang diterapkan padanya dengan konfigurasi firewall.
  • Periksa apakah konsultan migrasi OS/DB utama memiliki lisensi! Mintalah nama konsultan, s-user, dan tanggal sertifikasi. Buka pesan OSS ke BC-INS-MIG dan minta SAP untuk mengonfirmasi bahwa konsultan terbaru dan berlisensi.
  • Jika memungkinkan, mintalah seluruh tim proyek yang terkait dengan proyek migrasi VLDB dalam satu lokasi fisik dan tidak tersebar secara geografis di beberapa benua dan zona waktu.
  • Pastikan ada rencana fallback yang tepat dan itu adalah bagian dari jadwal keseluruhan.
  • Pilih model CPU Intel hitung rangkaian cepat untuk server ekspor R3load. Jangan gunakan model CPU "Penghemat Energi" karena memiliki performa yang lebih rendah dan tidak menggunakan server 4-soket. Intel Xeon E5 Platinum 8158 adalah contoh yang baik.

Praktik terbaik untuk menghindari masalah

  • Jangan subkontrak satu organisasi konsultasi untuk melakukan ekspor dan subkontrak organisasi konsultasi lain untuk melakukan impor. Kadang-kadang sistem sumber dialihdayakan dan dikelola oleh satu organisasi konsultan atau mitra dan pelanggan ingin bermigrasi ke Azure dan beralih ke mitra lain. Karena kopling yang ketat antara penyetelan dan konfigurasi ekspor dan impor, tugas ini tidak mungkin ditetapkan ke organisasi yang berbeda akan menghasilkan hasil yang baik.
  • Jangan ekonomis pada sumber daya perangkat keras Azure selama migrasi dan ditayangkan. VM Azure dikenakan biaya per menit dan dapat dikurangi ukurannya dengan mudah. Selama migrasi VLDB, gunakan VM paling kuat yang tersedia. Pelanggan telah berhasil melakukan siaran langsung pada sistem berukuran besar 200-250%, kemudian distabilkan saat menjalankan sistem yang terlalu besar. Setelah Anda memantau pemanfaatan sistem selama 4-6 minggu, VM dengan kapasitas berlebih berkurang dalam ukuran atau pematian untuk menurunkan biaya.