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.
Ada berbagai artikel untuk beban kerja SAP di Azure. 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 Pemantauan Azure yang Disempurnakan 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 pemasangan |
| 2002167 | Red Hat Enterprise Linux 7.x: Penginstalan dan peningkatan |
| 1597355 | Rekomendasi swap-space untuk Linux |
Sebagai pra-baca dokumen ini, tinjau Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP. Tinjau panduan lain dalam 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(Virtual Machines), lihat catatan SAP 1928533.
Panduan Konfigurasi IBM Db2 untuk Linux, UNIX, dan Windows untuk Pemasangan SAP di Azure VM
Konfigurasi Penyimpanan
Untuk gambaran umum jenis penyimpanan Azure untuk beban kerja SAP, lihat artikel Jenis Azure Storage untuk beban kerja SAP Semua file database harus disimpan pada disk penyimpanan blok Azure yang dipasang (Windows: NTFS, Linux: xfs, didukung per Db2 11.1, atau ext3).
Volume bersama 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{i> file database
- {i>Hosting
Jika Anda menggunakan disk berdasarkan Penyimpanan BLOB Halaman Azure atau Disk Terkelola, pernyataan yang dibuat dalam Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP berlaku untuk penyebaran dengan DBMS Db2 (Sistem Manajemen Database) juga.
Seperti yang dijelaskan sebelumnya di bagian umum dokumen, kuota pada throughput IOPS (operasi I/O per detik) untuk disk Azure ada. 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 cukup, dimungkinkan untuk menyimpan semua file database pada satu disk yang dipasang tunggal. 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.
Atau, Anda dapat menggunakan Kumpulan Penyimpanan Windows, yang hanya tersedia di Windows Server 2012 dan yang lebih tinggi seperti yang dijelaskan Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP. Di Linux, Anda dapat menggunakan LVM atau mdadm untuk membuat satu perangkat logis besar melalui beberapa disk.
Untuk Azure M-Series VM, Anda dapat mengurangi berdasarkan faktor penulisan latensi ke dalam log transaksi, dibandingkan dengan performa penyimpanan Azure Premium, saat menggunakan Azure Write Accelerator. Oleh karena itu, Anda harus menyebarkan Azure Write Accelerator untuk satu atau beberapa VHD 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 versi Db2 yang lebih lama, ukuran sektor 512 Byte harus digunakan. Disk SSD premium adalah asli 4-KB dan memiliki emulasi 512 Byte. Disk ultra menggunakan ukuran sektor 4-KB secara default. Anda dapat mengaktifkan ukuran sektor Byte 512 selama pembuatan disk Ultra. Detail tersedia Menggunakan disk ultra Azure. Ukuran sektor Byte 512 ini adalah prasyarat untuk versi IBM Db2 LUW yang lebih rendah dari 11,5.
Pada Windows menggunakan kumpulan Penyimpanan untuk jalur penyimpanan Db2 untuk log_dirdirektori , 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 ini adalah konfigurasi dasar untuk berbagai ukuran dan penggunaan SAP pada penyebaran Db2 dari kecil hingga x-besar.
Penting
Jenis VM yang tercantum di bawah ini adalah contoh yang memenuhi kriteria vCPU dan memori dari masing-masing kategori. Konfigurasi penyimpanan didasarkan pada penyimpanan premium Azure v1. Disk Premium SSD v2 dan Azure Ultra didukung penuh dengan IBM Db2 juga dan dapat digunakan untuk penyebaran. Gunakan nilai untuk kapasitas, throughput burst, dan burst IOPS untuk menentukan konfigurasi Ultra disk atau Premium SSD v2. Anda dapat membatasi IOPS untuk /db2/<SID>/log_dir kira-kira 5000 IOPS. Sesuaikan throughput dan IOPS dengan beban kerja tertentu jika rekomendasi garis besar ini tidak memenuhi persyaratan
Sistem SAP ekstra kecil: ukuran database 50 - 200 GB: contoh Pengelola Solusi
| Ukuran / Contoh 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 4 | /db2 | P6 | 1 | 240 | 50 | 64 | 3.500 | 170 | ||
| RAM: ~32 GiB | /db2/<SID>/sapdata |
P10 | 2 | 1,000 | 200 | 256 | 7\.000 | 340 | 256 KB |
Baca Saja |
| E4(d)s_v5 | /db2/<SID>/saptmp |
P6 | 1 | 240 | 50 | 128 | 3.500 | 170 | ||
| E4(d)as_v5 | /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
| Ukuran / Contoh 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 16 | /db2 | P6 | 1 | 240 | 50 | 64 | 3.500 | 170 | ||
| RAM: ~128 GiB | /db2/<SID>/sapdata |
P15 | 4 | 4.400 | 500 | 1.024 | 14.000 | 680 | 256 KB | Baca Saja |
| E16(d)s_v5 | /db2/<SID>/saptmp |
P6 | 2 | 480 | 100 | 128 | 7\.000 | 340 | 128 KB | |
| E16(d)as_v5 | /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
| Ukuran / Contoh 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 32 | /db2 | P6 | 1 | 240 | 50 | 64 | 3.500 | 170 | ||
| RAM: ~256 GiB | /db2/<SID>/sapdata |
P30 | 2 | 10,000 | 400 | 2.048 | 10,000 | 400 | 256 KB | Baca Saja |
| E32(d)s_v5 | /db2/<SID>/saptmp |
P10 | 2 | 1,000 | 200 | 256 | 7\.000 | 340 | 128 KB | |
| E32(d)as_v5 | /db2/<SID>/log_dir |
P20 | 2 | 4.600 | 300 | 1.024 | 7\.000 | 340 | 64 KB |
|
| M32ls | /db2/<SID>/offline_log_dir |
P15 | 1 | 1.100 | 125 | 256 | 3.500 | 170 |
Sistem SAP besar: ukuran database 750 - 2000 GB: Business Suite
| Ukuran / Contoh 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: 64 | /db2 | P6 | 1 | 240 | 50 | 64 | 3.500 | 170 | ||
| RAM: ~512 GiB | /db2/<SID>/sapdata |
P30 | 4 | 20.000 | 800 | 4.096 | 20.000 | 800 | 256 KB | Baca Saja |
| E64(d)s_v5 | /db2/<SID>/saptmp |
P15 | 2 | 2.200 | 250 | 512 | 7\.000 | 340 | 128 KB | |
| E64(d)as_v5 | /db2/<SID>/log_dir |
P20 | 4 | 9.200 | 600 | 2.048 | 14.000 | 680 | 64 KB |
|
| M64ls | /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
Terutama untuk sistem yang lebih besar, penting untuk mengevaluasi infrastruktur yang saat ini dijalankan sistem dan data konsumsi sumber daya dari sistem tersebut untuk menemukan kecocokan terbaik dari infrastruktur dan konfigurasi komputasi dan penyimpanan Azure.
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| vCPU: =>128 | /db2 | P10 | 1 | 500 | 100 | 128 | 3.500 | 170 | ||
| RAM: =>2.048 GiB | /db2/<SID>/sapdata |
P40 | 4 | 30.000 | 1.000 | 8.192 | 30.000 | 1.000 | 256 KB | Baca Saja |
| M128s_v2 | /db2/<SID>/saptmp |
P20 | 2 | 4.600 | 300 | 1.024 | 7\.000 | 340 | 128 KB | |
| M176s_2_v3 | /db2/<SID>/log_dir |
P30 | 4 | 20.000 | 800 | 4.096 | 20.000 | 800 | 64 KB |
Write- Accelerator |
| M176s_3_v3, M176s_4_v3 |
/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 dapat 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. 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 Stripe, disk) untuk menulis cadangan, semakin rendah throughput
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 Windows VSS. 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
Kluster Failover Windows Server (WSFC) juga dikenal sebagai Microsoft Cluster Server (MSCS) tidak didukung.
Pemulihan bencana ketersediaan tinggi Db2 (HADR) dengan didukung. Jika komputer virtual konfigurasi KETERSEDIAAN TINGGI memiliki resolusi nama kerja, penyiapan di Azure tidak berbeda dari penyiapan apa pun yang dilakukan secara lokal. Tidak disarankan untuk mengandalkan resolusi IP saja.
Jangan gunakan Geo-Replikasi untuk akun penyimpanan yang menyimpan disk database. Untuk detail selengkapnya, lihat Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP.
Penjaringan Dipercepat
Untuk penyebaran Db2 di Windows, sebaiknya gunakan fungsionalitas Azure Accelerated Networking seperti yang dijelaskan dalam dokumen Azure Accelerated Networking. Pertimbangkan juga rekomendasi yang dibuat di Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP.
Khusus untuk penyebaran Linux
Selama kuota IOPS saat ini per disk cukup, anda dapat menyimpan semua file database pada satu disk tunggal. Padahal Anda harus selalu memisahkan file data dan file log transaksi pada disk yang berbeda.
Jika throughput IOPS atau I/O dari satu Azure VHD tidak cukup, 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 membuat satu perangkat logis besar melalui beberapa disk.
Untuk disk yang berisi jalur penyimpanan Db2 untuk direktori dan saptmp Andasapdata, Anda harus menentukan ukuran sektor disk fisik 512 KB.
Lainnya
Semua area umum lainnya seperti Set Ketersediaan Azure atau pemantauan SAP juga berlaku untuk penyebaran VM dengan Database IBM. Area umum ini kami jelaskan dalam Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP.
Langkah berikutnya
Baca artikel: