Penyebaran IBM Db2 Azure Virtual Machines DBMS untuk beban kerja SAP
Dengan Microsoft Azure, Anda dapat memigrasikan aplikasi SAP yang sudah ada yang berjalan di IBM Db2 untuk Linux, UNIX, dan Windows (LUW) ke VM Azure. Dengan SAP di IBM Db2 untuk LUW, admin dan pengembang masih dapat menggunakan alat pengembangan dan administrasi yang sama, yang tersedia secara lokal. Informasi umum tentang menjalankan SAP Business Suite di IBM Db2 untuk LUW tersedia melalui SAP Community Network (SCN) di SAP di IBM Db2 untuk Linux, UNIX, dan Windows.
Untuk informasi selengkapnya dan pembaruan tentang SAP di Db2 untuk LUW di Azure, lihat Catatan SAP 2233094.
Berbagai artikel tentang beban kerja SAP di Azure telah diterbitkan. Kami rekomendasikan untuk memulai dengan Mulai menggunakan SAP di mesin virtual Azure, kemudian baca tentang area peminatan lainnya.
Catatan SAP berikut berhubungan dengan SAP di Azure terkait area yang dicakup dalam dokumen ini:
| Nomor Catatan | Judul |
|---|---|
| 1928533 | Aplikasi SAP di Azure: Produk dan jenis Azure VM yang didukung |
| 2015553 | SAP di Microsoft Azure: Prasyarat Dukungan |
| 1999351 | Pemecahan masalah meningkatkan pemantauan Azure untuk SAP |
| 2178632 | Metrik Pemantauan Utama untuk SAP di Microsoft Azure |
| 1409604 | Virtualisasi pada Windows: Pemantauan yang Ditingkatkan |
| 2191498 | SAP di Linux dengan Azure: Pemantauan yang ditingkatkan |
| 2233094 | DB6: Aplikasi SAP di Microsoft Azure menggunakan IBM DB2 untuk Linux, UNIX, dan Windows - Informasi Tambahan |
| 2243692 | Linux di Microsoft Azure (IaaS) VM: Masalah lisensi SAP |
| 1984787 | SUSE LINUX Enterprise Server 12: Catatan penginstalan |
| 2002167 | Red Hat Enterprise Linux 7.x: Penginstalan dan Upgrade |
| 1597355 | Rekomendasi swap-space untuk Linux |
Sebagai prasyarat untuk dokumen ini, Anda harus membaca dokumen Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP serta panduan lainnya dalam dokumentasi beban kerja SAP di Azure.
Dukungan Versi IBM Db2 untuk Linux, UNIX, dan Windows (LUW)
SAP di IBM Db2 untuk LUW di Layanan Microsoft Azure Virtual Machine didukung di Db2 versi 10.5.
Untuk informasi tentang produk SAP yang didukung dan jenis Azure VM, lihat Catatan SAP 1928533.
Panduan Konfigurasi IBM Db2 untuk Linux, UNIX, dan Windows untuk Pemasangan SAP di Azure VM
Konfigurasi penyimpanan
Untuk ringkasan jenis penyimpanan Azure untuk beban kerja SAP, lihat artikel Jenis Azure Storage untuk beban kerja SAP Semua file database harus disimpan di disk penyimpanan blok Azure yang terpasang (Windows: NTFS, Linux: xfs atau ext3). Volume berbagi jarak jauh seperti layanan Azure dalam skenario yang tercantum TIDAK didukung untuk file database Db2:
Microsoft Azure File Service untuk semua OS tamu
Azure NetApp Files untuk Db2 berjalan di OS tamu Windows.
Volume berbagi jarak jauh seperti layanan Azure dalam skenario yang tercantum didukung untuk file database Db2:
- Hosting data Db2 berbasis OS tamu Linux dan file log pada NFS yang dibagi di-hosting di Azure NetApp Files didukung!
Dengan menggunakan disk berdasarkan penyimpanan BLOB Halaman Azure atau Disk Terkelola, pernyataan yang dibuat di Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP juga berlaku untuk penyebaran dengan Db2 DBMS.
Seperti yang dijelaskan sebelumnya di bagian umum dokumen, terdapat kuota pada throughput IOPS untuk disk Azure. Kuota yang tepat bergantung pada jenis VM yang digunakan. Daftar jenis VM dengan kuotanya dapat ditemukan di sini (Linux) dan di sini (Windows).
Selama kuota IOPS saat ini per disk mencukupi, semua file database dapat disimpan dalam satu disk yang terpasang. Meskipun demikian, Anda harus selalu memisahkan file data dan file log transaksi di disk/VHD yang berbeda.
Untuk pertimbangan performa, lihat juga bab 'Pertimbangan Keamanan dan Performa Data untuk Direktori Database' dalam panduan pemasangan SAP.
Sebagai alternatif, Anda dapat menggunakan Windows Storage Pools (hanya tersedia di Windows Server 2012 dan versi yang lebih tinggi) seperti yang dijelaskan di Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP atau LVM atau mdadm di Linux untuk membuat satu perangkat logis besar pada beberapa disk.
Untuk Azure M-Series VM, penulisan latensi ke dalam log transaksi dapat berkurang karena beberapa faktor, dibandingkan dengan performa penyimpanan Azure Premium, saat menggunakan Azure Write Accelerator. Oleh karena itu, Anda harus menggunakan Azure Write Accelerator untuk VHD(s) yang membentuk volume untuk log transaksi Db2. Detail dapat dibaca dalam dokumen Write Accelerator.
Dukungan rilis IBM Db2 LUW 11.5 untuk ukuran sektor 4-KB. Meskipun Anda perlu mengaktifkan penggunaan ukuran sektor 4-KB dengan 11.5 dengan pengaturan konfigurasi db2set DB2_4K_DEVICE_SUPPORT=ON seperti yang didokumentasikan dalam:
Untuk Db2 versi sebelumnya, ukuran sektor 512-Byte harus digunakan. Disk SSD premium adalah 4-KB asli dan memiliki emulasi 512-Byte. Disk ultra menggunakan ukuran sektor 4-KB secara default. Anda dapat mengaktifkan ukuran sektor 512-Byte selama pembuatan Disk ultra. Detail tersedia Menggunakan disk ultra Azure. Ukuran sektor 512 Byte ini merupakan prasyarat untuk IBM Db2 LUW versi yang lebih rendah dari 11,5.
Pada Windows yang menggunakan kumpulan Storage untuk jalur penyimpanan Db2 untuk direktori log_dir, sapdata, dan saptmp, Anda harus menentukan ukuran sektor disk fisik 512-Byte. Saat menggunakan Windows Storage Pools, Anda harus membuat kumpulan penyimpanan secara manual melalui antarmuka baris perintah menggunakan parameter -LogicalSectorSizeDefault. Untuk informasi selengkapnya, lihat New-StoragePool.
Rekomendasi tentang VM dan struktur disk untuk penyebaran IBM Db2
IBM Db2 untuk Aplikasi SAP NetWeaver didukung pada semua jenis VM yang tercantum dalam catatan dukungan SAP 1928533. Keluarga VM yang direkomendasikan untuk menjalankan database IBM Db2 adalah Esd_v4/Eas_v4/Es_v3 dan seri M/M_v2 untuk database multi-terabyte besar. Performa penulisan disk log transaksi IBM Db2 dapat ditingkatkan dengan mengaktifkan Write Accelerator seri M.
Berikut konfigurasi dasar untuk berbagai ukuran dan penggunaan penyebaran SAP di Db2 dari kecil hingga besar. Daftar ini didasarkan pada penyimpanan premium Azure. Namun, disk Azure Ultra juga didukung penuh dengan Db2 dan dapat digunakan juga. Gunakan nilai untuk kapasitas, throughput burst, dan IOPS burst untuk menentukan konfigurasi disk Ultra. Anda dapat membatasi IOPS untuk /db2/<SID>/log_dir kira-kira 5000 IOPS.
Sistem SAP ekstra kecil: ukuran database 50 - 200 GB: contoh Pengelola Solusi
| Nama / Ukuran VM | Titik pemasangan Db2 | Disk Premium Azure | # dari Disk | IOPS | Through- put [MB/dtk] |
Size [GB] | Burst IOPS | Burst Through- put [GB] |
Ukuran garis | Penembolokan |
|---|---|---|---|---|---|---|---|---|---|---|
| E4ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 4 | /db2/<SID>/sapdata |
P10 | 2 | 1\.000 | 200 | 256 | 7\.000 | 340 | 256 KB |
ReadOnly |
| RAM: 32 GiB | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3\.500 | 170 | ||
/db2/<SID>/log_dir |
P6 | 2 | 480 | 100 | 128 | 7\.000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3\.500 | 170 |
Sistem SAP kecil: ukuran database 200 - 750 GB: Business Suite kecil
| Nama / Ukuran VM | Titik pemasangan Db2 | Disk Premium Azure | # dari Disk | IOPS | Through- put [MB/dtk] |
Size [GB] | Burst IOPS | Burst Through- put [GB] |
Ukuran garis | Penembolokan |
|---|---|---|---|---|---|---|---|---|---|---|
| E16ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 16 | /db2/<SID>/sapdata |
P15 | 4 | 4,400 | 500 | 1.024 | 14.000 | 680 | 256 KB | ReadOnly |
| RAM: 128 GiB | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P15 | 2 | 2\.200 | 250 | 512 | 7\.000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P10 | 1 | 500 | 100 | 128 | 3\.500 | 170 |
Sistem SAP sedang: ukuran database 500 - 1000 GB: Business Suite kecil
| Nama / Ukuran VM | Titik pemasangan Db2 | Disk Premium Azure | # dari Disk | IOPS | Through- put [MB/dtk] |
Size [GB] | Burst IOPS | Burst Through- put [GB] |
Ukuran garis | Penembolokan |
|---|---|---|---|---|---|---|---|---|---|---|
| E32ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 32 | /db2/<SID>/sapdata |
P30 | 2 | 10.000 | 400 | 2.048 | 10.000 | 400 | 256 KB | ReadOnly |
| RAM: 256 GiB | /db2/<SID>/saptmp |
P10 | 2 | 1\.000 | 200 | 256 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P20 | 2 | 4\.600 | 300 | 1.024 | 7\.000 | 340 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P15 | 1 | 1\.100 | 125 | 256 | 3\.500 | 170 |
Sistem SAP besar: ukuran database 750 - 2000 GB: Business Suite
| Nama / Ukuran VM | Titik pemasangan Db2 | Disk Premium Azure | # dari Disk | IOPS | Through- put [MB/dtk] |
Size [GB] | Burst IOPS | Burst Through- put [GB] |
Ukuran garis | Penembolokan |
|---|---|---|---|---|---|---|---|---|---|---|
| E64ds_v4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3\.500 | 170 | ||
| vCPU: 64 | /db2/<SID>/sapdata |
P30 | 4 | 20.000 | 800 | 4.096 | 20.000 | 800 | 256 KB | ReadOnly |
| RAM: 504 GiB | /db2/<SID>/saptmp |
P15 | 2 | 2\.200 | 250 | 512 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P20 | 4 | 9\.200 | 600 | 2.048 | 14.000 | 680 | 64 KB |
||
/db2/<SID>/offline_log_dir |
P20 | 1 | 2\.300 | 150 | 512 | 3\.500 | 170 |
Sistem SAP multi-terabyte besar: ukuran database 2 TB+: Sistem Global Business Suite
| Nama / Ukuran VM | Titik pemasangan Db2 | Disk Premium Azure | # dari Disk | IOPS | Through- put [MB/dtk] |
Size [GB] | Burst IOPS | Burst Through- put [GB] |
Ukuran garis | Penembolokan |
|---|---|---|---|---|---|---|---|---|---|---|
| M128s | /db2 | P10 | 1 | 500 | 100 | 128 | 3\.500 | 170 | ||
| vCPU: 128 | /db2/<SID>/sapdata |
P40 | 4 | 30.000 | 1.000 | 8.192 | 30.000 | 1.000 | 256 KB | ReadOnly |
| RAM: 2048 GiB | /db2/<SID>/saptmp |
P20 | 2 | 4\.600 | 300 | 1.024 | 7\.000 | 340 | 128 KB | |
/db2/<SID>/log_dir |
P30 | 4 | 20.000 | 800 | 4.096 | 20.000 | 800 | 64 KB |
Write- Accelerator |
|
/db2/<SID>/offline_log_dir |
P30 | 1 | 5\.000 | 200 | 1.024 | 5\.000 | 200 |
Menggunakan Azure NetApp Files
Penggunaan volume NFS v4.1 berdasarkan Azure NetApp Files (ANF) didukung dengan IBM Db2, yang dihosting di Suse atau Red Hat Linux guest OS. Anda harus membuat setidaknya empat volume berbeda yang daftar seperti:
- Volume bersama untuk saptmp1, sapmnt, usr_sap,
<sid>_home, db2<sid>_home, db2_software - Satu volume data untuk sapdata1 ke sapdatan
- Satu volume log untuk direktori log redo
- Satu volume untuk arsip log dan cadangan
Volume potensial kelima bisa menjadi volume ANF yang Anda gunakan untuk lebih banyak cadangan jangka panjang yang Anda gunakan untuk snapshot dan menyimpan snapshot di penyimpanan Azure Blob.
Konfigurasi bisa terlihat seperti yang ditunjukkan di sini
Tingkat performa dan ukuran volume yang dihosting ANF harus dipilih berdasarkan persyaratan performa. Namun, kami sarankan mengambil tingkat performa Ultra untuk data dan volume log. Hal ini tidak didukung untuk mencampur penyimpanan blok dan jenis penyimpanan bersama untuk data dan volume log.
Pada opsi pemasangan, pemasangan volume tersebut dapat terlihat seperti (Anda perlu mengganti <SID> dan <sid> dengan SID sistem SAP Anda):
vi /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2shared /mnt
mkdir -p /db2/Software /db2/AN1/saptmp /usr/sap/<SID> /sapmnt/<SID> /home/<sid>adm /db2/db2<sid> /db2/<SID>/db2_software
mkdir -p /mnt/Software /mnt/saptmp /mnt/usr_sap /mnt/sapmnt /mnt/<sid>_home /mnt/db2_software /mnt/db2<sid>
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2data /mnt
mkdir -p /db2/AN1/sapdata/sapdata1 /db2/AN1/sapdata/sapdata2 /db2/AN1/sapdata/sapdata3 /db2/AN1/sapdata/sapdata4
mkdir -p /mnt/sapdata1 /mnt/sapdata2 /mnt/sapdata3 /mnt/sapdata4
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2log /mnt
mkdir /db2/AN1/log_dir
mkdir /mnt/log_dir
umount /mnt
mount -t nfs -o rw,hard,sync,rsize=262144,wsize=262144,sec=sys,vers=4.1,tcp 172.17.10.4:/db2backup /mnt
mkdir /db2/AN1/backup
mkdir /mnt/backup
mkdir /db2/AN1/offline_log_dir /db2/AN1/db2dump
mkdir /mnt/offline_log_dir /mnt/db2dump
umount /mnt
Catatan
Opsi mount keras dan sinkronisasi diperlukan
Pencadangan/Pemulihan
Fungsi pencadangan/pemulihan untuk IBM Db2 untuk LUW didukung sama seperti pada Sistem Operasi Windows Server standar dan Hyper-V.
Pastikan Anda memiliki strategi pencadangan database yang valid.
Seperti dalam penyebaran bare-metal, performa pencadangan/pemulihan bergantung pada berapa banyak volume yang dapat dibaca secara paralel dan throughput volume tersebut. Selain itu, konsumsi CPU yang digunakan oleh kompresi cadangan dapat memainkan peran penting pada VM dengan maksimal delapan alur CPU. Oleh karena itu, dapat diasumsikan bahwa:
- Semakin sedikit jumlah disk yang digunakan untuk menyimpan perangkat database, throughput pembacaan secara keseluruhan semakin rendah
- Semakin kecil jumlah alur CPU di VM, dampak konsumsi cadangan semakin parah
- Semakin sedikit target (Direktori Garis, disk) tempat tujuan penulisan pencadangan, throughput-nya semakin rendah
Untuk meningkatkan jumlah target untuk ditulis, dua opsi dapat digunakan/digabungkan, bergantung pada kebutuhan Anda:
- Menghapus volume target pencadangan melalui beberapa disk untuk meningkatkan throughput IOPS pada volume bergaris itu
- Menggunakan lebih dari satu direktori target tempat penulisan cadangan
Catatan
Db2 di Windows tidak mendukung teknologi VSS Windows. Akibatnya, pencadangan VM konsisten aplikasi oleh Layanan Azure Backup tidak dapat digunakan untuk VM tempat Db2 DBMS disebarkan.
Ketersediaan Tinggi dan Pemulihan Bencana
Linux Pacemaker
Penting
Untuk Db2 versi 11.5.6 dan yang lebih tinggi, sebaiknya gunakan Solusi terintegrasi menggunakan Pacemaker dari IBM.
- Solusi terintegrasi menggunakan Pacemaker
- Konfigurasi alternatif atau tambahan yang tersedia di Microsoft Azure Pemulihan bencana high availability (HADR) Db2 dengan pacemaker didukung. Sistem operasi SLES dan RHEL didukung. Konfigurasi ini memungkinkan ketersediaan IBM Db2 untuk SAP yang tinggi. Panduan penyebaran:
- SLES: Ketersediaan tinggi IBM Db2 LUW di Azure VM di SUSE Linux Enterprise Server dengan Pacemaker
- RHEL: Ketersediaan tinggi IBM Db2 LUW di Azure VM di Red Hat Enterprise Linux Server
Windows Cluster Server
Microsoft Cluster Server (MSCS) tidak didukung.
Pemulihan bencana ketersediaan tinggi Db2 (HADR) dengan didukung. Jika komputer virtual dengan konfigurasi HA memiliki resolusi nama kerja, pengaturan di Azure tidak berbeda dengan semua pengaturan yang dilakukan secara lokal. Sebaiknya jangan hanya mengandalkan resolusi IP.
Jangan gunakan Replikasi Geografis untuk akun penyimpanan yang menyimpan disk database. Untuk detail selengkapnya, lihat Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP.
Jaringan yang Dipercepat
Untuk penyebaran Db2 di Windows, sebaiknya gunakan fungsionalitas Azure dari Jaringan yang Dipercepat seperti yang dijelaskan dalam dokumen Jaringan yang Dipercepat Azure. Pertimbangkan juga rekomendasi yang dibuat di Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP.
Khusus untuk penyebaran Linux
Selama kuota IOPS per disk saat mencukupi, semua file database dapat disimpan dalam satu disk. Padahal Anda harus selalu memisahkan file data dan file log transaksi pada disk yang berbeda.
Jika throughput IOPS atau I/O dari Azure VHD tunggal tidak mencukupi, Anda dapat menggunakan LVM (Logical Volume Manager) atau MDADM seperti yang dijelaskan dalam dokumen Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP untuk buat satu perangkat logis besar melalui beberapa disk. Untuk disk yang berisi jalur penyimpanan Db2 untuk direktori sapdata dan saptmp, Anda harus menentukan ukuran sektor disk fisik sebesar 512 KB.
Lainnya
Semua area umum lainnya seperti Azure Availability Set atau pemantauan SAP juga berlaku seperti yang dijelaskan dalam dokumen Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP untuk penyebaran VM dengan Database IBM.
Langkah berikutnya
Baca artikel