Ketersediaan tinggi IBM Db2 LUW di Azure Virtual Machines di Red Hat Enterprise Linux Server
IBM Db2 untuk Linux, UNIX, dan Windows (LUW) dalam konfigurasi ketersediaan tinggi dan pemulihan bencana (HADR) berisi satu node yang menjalankan instans database utama dan minimal satu node yang menjalankan instans database sekunder. Perubahan pada instans database utama direplikasi ke instans database sekunder secara sinkron atau asinkron, tergantung konfigurasi Anda.
Catatan
Artikel ini berisi referensi ke istilah yang tidak lagi digunakan Microsoft. Ketika istilah ini dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.
Artikel ini menjelaskan cara menggunakan dan mengonfigurasi komputer virtual (VM) Azure, menginstal kerangka kerja kluster, dan menginstal IBM Db2 LUW dengan konfigurasi HADR.
Artikel ini tidak membahas cara menginstal dan mengonfigurasi IBM Db2 LUW dengan instalasi perangkat lunak HADR atau SAP. Untuk membantu Anda menyelesaikan tugas-tugas ini, kami menyediakan referensi ke panduan penginstalan SAP dan IBM. Artikel ini berfokus pada bagian yang khusus untuk lingkungan Azure.
Versi IBM Db2 yang didukung adalah 10.5 dan yang lebih baru, seperti yang didokumentasikan dalam catatan SAP 1928533.
Sebelum Anda memulai penginstalan, lihat catatan dan dokumentasi SAP berikut:
| Catatan SAP | Deskripsi |
|---|---|
| 1928533 | Aplikasi SAP di Azure: Jenis produk dan Azure VM yang didukung |
| 2015553 | SAP di Azure: Prasyarat dukungan |
| 2178632 | Metrik pemantauan utama untuk SAP di Azure |
| 2191498 | SAP di Linux dengan Azure: Pemantauan yang ditingkatkan |
| 2243692 | Linux di VM Azure (IaaS): Masalah lisensi SAP |
| 2002167 | Red Hat Enterprise Linux 7.x: Penginstalan dan peningkatan |
| 2694118 | Red Hat Enterprise Linux HA Add-On di Azure |
| 1999351 | Pemecahan masalah meningkatkan pemantauan Azure untuk SAP |
| 2233094 | DB6: Aplikasi SAP di Azure yang menggunakan IBM Db2 untuk Linux, UNIX, dan Windows - informasi tambahan |
| 1612105 | DB6: FAQ mengenai Db2 dengan HADR |
Gambaran Umum
Untuk mencapai ketersediaan tinggi, IBM Db2 LUW dengan HADR diinstal pada setidaknya dua komputer virtual Azure, yang disebarkan dalam set skala komputer virtual dengan orkestrasi fleksibel di seluruh zona ketersediaan atau dalam set ketersediaan.
Grafik berikut ini menampilkan setup dari dua komputer virtual Azure server database. Kedua komputer virtual Azure server database memiliki penyimpanan sendiri yang terpasang dan sedang berjalan. Di HADR, satu instans database di salah satu Azure VM memiliki peran instans utama. Semua klien tersambung dengan instans utama ini. Semua perubahan dalam transaksi database akan disimpan secara lokal dalam log transaksi Db2. Karena catatan log transaksi disimpan secara lokal, catatan tersebut ditransfer melalui TCP/IP ke instans database di server database kedua, server siaga, atau instans siaga. Instans siaga memperbarui database lokal dengan meneruskan catatan log transaksi yang ditransfer. Dengan cara ini, server siaga akan tetap sinkron dengan server utama.
HADR hanyalah fungsionalitas replikasi. HADR tidak memiliki deteksi kegagalan dan tidak memiliki pengambil alihan atau fasilitas failover. Pengambilalihan atau transfer ke server siaga harus dimulai secara manual oleh administrator database. Untuk melakukan pengambilalihan otomatis dan deteksi kegagalan, Anda bisa menggunakan fitur pengklusteran Linux Pacemaker. Pacemaker memantau dua instans server database. Saat instans server database utama lumpuh, Pacemaker memulai ambil alih HADR otomatis dengan server siaga. Pacemaker juga memastikan alamat IP virtual ditetapkan ke server utama yang baru.
Agar server aplikasi SAP tersambung ke database utama, Anda memerlukan nama host virtual dan alamat IP virtual. Setelah failover, server aplikasi SAP terhubung ke instans database utama baru. Di lingkungan Azure, diperlukan Azure load balancar untuk menggunakan alamat IP virtual dengan cara yang diperlukan untuk HADR IBM Db2.
Untuk membantu Anda sepenuhnya memahami cara IBM Db2 LUW dengan HADR dan Pacemaker menyesuaikan dengan setup sistem SAP yang sangat tersedia, gambar berikut memberikan gambaran umum tentang setup sistem SAP yang sangat tersedia berdasarkan database IBM Db2. Artikel ini hanya membahas IBM Db2, tetapi juga memberikan referensi ke artikel lain tentang cara mengatur komponen lain dari sistem SAP.
Gambaran umum tentang langkah-langkah yang diperlukan
Untuk menggunakan konfigurasi IBM Db2, Anda harus mengikuti langkah-langkah berikut:
- Rencanakan lingkungan Anda.
- Menyebarkan komputer virtual.
- Perbarui RHEL Linux dan konfigurasikan sistem file.
- Instal dan konfigurasikan Pacemaker.
- Siapkan kluster glusterfs atau Azure NetApp Files
- Instal ASCS/ERS pada kluster terpisah.
- Instal database IBM Db2 dengan opsi Ketersediaan Tinggi/Terdistribusi (SWPM).
- Instal lalu buat node dan instans database sekunder, kemudian konfigurasikan HADR.
- Pastikan HADR berfungsi.
- Terapkan konfigurasi Pacemaker untuk mengontrol IBM Db2.
- Konfigurasikan Azure Load Balancer.
- Instal server aplikasi utama dan dialog.
- Periksa dan sesuaikan konfigurasi server aplikasi SAP.
- Lakukan pengujian pengambilalihan dan failover.
Rencanakan infrastruktur Azure untuk meng-hosting IBM Db2 LUW dengan HADR
Selesaikan proses perencanaan sebelum Anda mengeksekusi penggunaan. Perencanaan membangun fondasi untuk menggunakan konfigurasi Db2 dengan HADR di Azure. Elemen kunci yang harus menjadi bagian dari perencanaan untuk IMB Db2 LUW (bagian database lingkungan SAP) tercantum dalam tabel berikut:
| Topik | Deskripsi singkat |
|---|---|
| Menentukan grup sumber Azure | Grup sumber daya tempat Anda menyebarkan VM, jaringan virtual, Azure Load Balancer, dan sumber daya lainnya. Bisa yang sudah ada atau yang baru. |
| Definisi Subnet/jaringan virtual | Di mana VM untuk IBM Db2 dan Azure Load Balancer sedang digunakan. Bisa yang sudah ada atau yang baru dibuat. |
| Komputer virtual yang meng-hosting IBM Db2 LUW | Ukuran VM, penyimpanan, jaringan, alamat IP. |
| Nama host virtual dan IP virtual untuk database IBM Db2 | IP virtual atau nama host digunakan untuk koneksi server aplikasi SAP. db-virt-hostname, db-virt-ip. |
| Fencing Azure | Metode untuk menghindari situasi split brain. |
| Penyeimbang Beban Azure | Penggunaan Port pemeriksaan Standar (disarankan), untuk database Db2 (rekomendasi kami 62500) port probe. |
| Resolusi Nama | Cara kerja resolusi nama di lingkungan. Layanan DNS sangat disarankan. File host lokal bisa digunakan. |
Untuk informasi selengkapnya tentang Linux Pacemaker di Azure, lihat Menyiapkan Pacemaker di Red Hat Enterprise Linux di Azure.
Penting
Untuk Db2 versi 11.5.6 dan yang lebih tinggi, sebaiknya gunakan Solusi terintegrasi menggunakan Pacemaker dari IBM.
Penggunaan di Red Hat Enterprise Linux
Agen sumber untuk IBM Db2 LUW termasuk dalam Red Hat Enterprise Linux Server HA Addon. Untuk setup yang dijelaskan dalam dokumen ini, Anda harus menggunakan Red Hat Enterprise Linux untuk SAP. Marketplace Azure berisi gambar untuk Red Hat Enterprise Linux 7.4 untuk SAP atau yang lebih baru yang dapat Anda gunakan untuk menggunakan komputer virtual baru. Perhatikan berbagai model dukungan atau layanan yang ditawarkan oleh Red Hat melalui Azure Marketplace saat Anda memilih gambar VM di Azure VM Marketplace.
Host: Pembaruan DNS
Buat daftar semua nama host, termasuk nama host virtual, lalu perbarui server DNS Anda untuk mengaktifkan alamat IP yang tepat ke resolusi nama host. Jika tidak ada server DNS atau Anda tidak bisa memperbarui dan membuat entri DNS, Anda harus menggunakan file host lokal dari setiap VM yang berpartisipasi dalam skenario ini. Jika Anda menggunakan entri file host, pastikan entri diterapkan ke semua VM di lingkungan sistem SAP. Akan tetapi, sebaiknya Anda menggunakan DNS yang, idealnya, meluas ke Azure
Penyebaran manual
Pastikan OS yang dipilih didukung oleh IBM/SAP untuk IBM Db2 LUW. Daftar versi OS yang didukung untuk rilis Azure VM dan Db2 tersedia di catatan SAP 1928533. Daftar rilis OS berdasarkan rilis Db2 individu tersedia di Matriks Ketersediaan Produk SAP. Kami sangat merekomendasikan minimal Red Hat Enterprise Linux 7.4 untuk SAP karena peningkatan kinerja terkait Azure dalam versi Red Hat Enterprise Linux ini atau yang lebih baru.
- Buat atau pilih grup sumber.
- Buat atau pilih jaringan virtual dan subnet.
- Pilih jenis penyebaran yang sesuai untuk komputer virtual SAP. Biasanya set skala komputer virtual dengan orkestrasi fleksibel.
- Buat Komputer Virtual 1.
- Gunakan Red Hat Enterprise Linux untuk gambar SAP di Azure Marketplace.
- Pilih set skala, zona ketersediaan, atau set ketersediaan yang dibuat di langkah 3.
- Buat Komputer Virtual 2.
- Gunakan Red Hat Enterprise Linux untuk gambar SAP di Azure Marketplace.
- Pilih set skala, zona ketersediaan, atau set ketersediaan yang dibuat di langkah 3 (bukan zona yang sama seperti pada langkah 4).
- Tambahkan disk data ke VM, lalu lihat rekomendasi penyiapan sistem file dalam artikel Penyebaran IBM Db2 Azure Virtual Machines DBMS untuk beban kerja SAP.
Menginstal lingkungan IBM Db2 LUW dan SAP
Sebelum Anda memulai penginstalan lingkungan SAP berdasarkan IBM Db2 LUW, tinjau dokumentasi berikut:
- Dokumentasi Azure.
- Dokumentasi SAP.
- Dokumentasi IBM.
Tautan ke dokumentasi ini diberikan di bagian pengantar artikel ini.
Baca panduan penginstalan SAP tentang menginstal aplikasi berbasis NetWeaver di IBM Db2 LUW. Anda bisa menemukan panduan di portal Bantuan SAP dengan menggunakan SAP Installation Guide Finder.
Anda dapat mengurangi jumlah panduan yang ditampilkan di portal dengan mengatur filter berikut:
- Saya ingin: Menginstal sistem baru.
- Database Saya: IBM Db2 untuk Linux, Unix, dan Windows.
- Filter tambahan untuk versi SAP NetWeaver, konfigurasi tumpukan, atau sistem operasi.
Aturan firewall Red Hat
Red Hat Enterprise Linux memiliki firewall yang diaktifkan secara default.
#Allow access to SWPM tool. Rule is not permanent.
sudo firewall-cmd --add-port=4237/tcp
Petunjuk instalasi untuk menyiapkan IBM Db2 LUW dengan HADR
Untuk menyiapkan instans database IBM Db2 LUW utama:
- Gunakan opsi ketersediaan tinggi atau terdistribusi.
- Instal instans Database dan SAP ASCS/ERS.
- Ambil cadangan database yang baru diinstal.
Penting
Tuliskan "Port Komunikasi Database" yang diatur selama penginstalan. Nomor port untuk kedua instans database harus sama.
Pengaturan IBM Db2 HADR untuk Azure
Saat Anda menggunakan agen fencing Azure Pacemaker, atur parameter berikut:
- Durasi HADR peer window (detik) (HADR_PEER_WINDOW) = 240
- Nilai batas waktu HADR (HADR_TIMEOUT) = 45
Kami menyarankan parameter sebelumnya berdasarkan pengujian failover/ambil alih awal. Anda harus menguji fungsionalitas failover dan pengalihan yang tepat dengan pengaturan parameter ini. Karena konfigurasi individu dapat bervariasi, parameter dapat memerlukan penyesuaian.
Catatan
Khusus untuk IBM Db2 yang memiliki konfigurasi HADR dengan startup normal: Instans database sekunder atau siaga harus siap dan berjalan sebelum Anda dapat memulai instans database utama.
Catatan
Untuk penginstalan dan konfigurasi yang khusus untuk Azure dan Pacemaker: Selama prosedur penginstalan melalui SAP Software Provisioning Manager, ada pertanyaan eksplisit mengenai ketersediaan tinggi untuk IBM Db2 LUW:
- Jangan pilih IBM Db2 pureScale.
- Jangan pilih Instal IBM Tivoli System Automation untuk Multiplatform.
- Jangan pilih Buat file konfigurasi kluster.
Untuk menyiapkan server database Siaga dengan menggunakan prosedur salinan sistem homogen SAP, jalankan langkah-langkah berikut:
- Pilih opsi Salinan sistem>Sistem target>Terdistribusi>Instans database.
- Sebagai metode salin, pilih Sistem Homogen sehingga Anda dapat menggunakan cadangan untuk mengembalikan cadangan pada instans server siaga.
- Begitu Anda sampai di langkah keluar untuk mengembalikan database untuk salinan sistem homogen, keluar dari penginstal. Kembalikan database dari cadangan host utama. Semua fase instalasi berikutnya telah dijalankan di server database utama.
Aturan Red Hat firewall untuk DB2 HADR
Tambahkan aturan firewall untuk memungkinkan lalu lintas ke DB2 dan antara DB2 agar HADR berfungsi:
- Port komunikasi database. Jika menggunakan partisi, tambahkan port tersebut juga.
- Port HADR (nilai parameter DB2 HADR_LOCAL_SVC).
- Port probe Azure.
sudo firewall-cmd --add-port=<port>/tcp --permanent
sudo firewall-cmd --reload
Pemeriksaan IBM Db2 HADR
Untuk tujuan demonstrasi dan prosedur yang dijelaskan dalam artikel ini, database SID adalah ID2.
Setelah Anda mengonfigurasi HADR dan statusnya adalah PEER dan TERSAMBUNG pada simpul utama dan siaga, lakukan pemeriksaan berikut:
Execute command as db2<sid> db2pd -hadr -db <SID>
#Primary output:
Database Member 0 -- Database ID2 -- Active -- Up 1 days 15:45:23 -- Date 2019-06-25-10.55.25.349375
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
LOG_STREAM_ID = 0
HADR_STATE = PEER
HADR_FLAGS =
PRIMARY_MEMBER_HOST = az-idb01
PRIMARY_INSTANCE = db2id2
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = az-idb02
STANDBY_INSTANCE = db2id2
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.076494 (1561460105)
HEARTBEAT_INTERVAL(seconds) = 7
HEARTBEAT_MISSED = 5
HEARTBEAT_EXPECTED = 52
HADR_TIMEOUT(seconds) = 30
TIME_SINCE_LAST_RECV(seconds) = 5
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 369280
PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
HADR_LOG_GAP(bytes) = 132242668
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_RECV_BUF_SIZE(pages) = 2048
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 1000
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 300
PEER_WINDOW_END = 06/25/2019 11:12:03.000000 (1561461123)
READS_ON_STANDBY_ENABLED = N
#Secondary output:
Database Member 0 -- Database ID2 -- Standby -- Up 1 days 15:45:18 -- Date 2019-06-25-10.56.19.820474
HADR_ROLE = STANDBY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 0
LOG_STREAM_ID = 0
HADR_STATE = PEER
HADR_FLAGS =
PRIMARY_MEMBER_HOST = az-idb01
PRIMARY_INSTANCE = db2id2
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = az-idb02
STANDBY_INSTANCE = db2id2
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = CONNECTED
HADR_CONNECT_STATUS_TIME = 06/25/2019 10:55:05.078116 (1561460105)
HEARTBEAT_INTERVAL(seconds) = 7
HEARTBEAT_MISSED = 0
HEARTBEAT_EXPECTED = 10
HADR_TIMEOUT(seconds) = 30
TIME_SINCE_LAST_RECV(seconds) = 1
PEER_WAIT_LIMIT(seconds) = 0
LOG_HADR_WAIT_CUR(seconds) = 0.000
LOG_HADR_WAIT_RECENT_AVG(seconds) = 598.000027
LOG_HADR_WAIT_ACCUMULATED(seconds) = 598.000
LOG_HADR_WAIT_COUNT = 1
SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 367360
PRIMARY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
HADR_LOG_GAP(bytes) = 0
STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000012.LOG, 14151, 3685322855
STANDBY_RECV_REPLAY_GAP(bytes) = 0
PRIMARY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_REPLAY_LOG_TIME = 06/25/2019 10:45:42.000000 (1561459542)
STANDBY_RECV_BUF_SIZE(pages) = 2048
STANDBY_RECV_BUF_PERCENT = 0
STANDBY_SPOOL_LIMIT(pages) = 1000
STANDBY_SPOOL_PERCENT = 0
STANDBY_ERROR_TIME = NULL
PEER_WINDOW(seconds) = 1000
PEER_WINDOW_END = 06/25/2019 11:12:59.000000 (1561461179)
READS_ON_STANDBY_ENABLED = N
Mengonfigurasi Azure Load Balancer
Selama konfigurasi VM, Anda memiliki opsi untuk membuat atau memilih keluar dari load balancer di bagian jaringan. Ikuti langkah-langkah di bawah ini, untuk menyiapkan load balancer standar untuk penyiapan ketersediaan tinggi database DB2.
Ikuti langkah-langkah dalam Membuat load balancer untuk menyiapkan load balancer standar untuk sistem SAP ketersediaan tinggi dengan menggunakan portal Azure. Selama penyiapan load balancer, pertimbangkan poin-poin berikut:
- Konfigurasi IP Frontend: Buat IP front-end. Pilih jaringan virtual dan nama subnet yang sama dengan komputer virtual database Anda.
- Kumpulan Backend: Buat kumpulan back-end dan tambahkan VM database.
- Aturan masuk: Buat aturan penyeimbangan beban. Ikuti langkah yang sama untuk kedua aturan penyeimbangan beban.
- Alamat IP frontend: Pilih IP front-end.
- Kumpulan backend: Pilih kumpulan back-end.
- Port ketersediaan tinggi: Pilih opsi ini.
- Protokol: Pilih TCP.
- Pemeriksaan Kesehatan: Buat pemeriksaan kesehatan dengan detail berikut:
- Protokol: Pilih TCP.
- Port: Misalnya, 625<instance-no.>.
- Interval: Masukkan 5.
- Ambang Probe: Masukkan 2.
- Batas waktu menganggur (menit): Masukkan 30.
- Aktifkan IP Mengambang: Pilih opsi ini.
Catatan
Properti numberOfProbeskonfigurasi pemeriksaan kesehatan , atau dikenal sebagai Ambang tidak sehat di portal, tidak dihormati. Untuk mengontrol jumlah pemeriksaan berturut-turut yang berhasil atau gagal, atur properti probeThreshold ke 2. Saat ini tidak dimungkinkan untuk mengatur properti ini dengan menggunakan portal Azure, jadi gunakan perintah Azure CLI atau PowerShell.
Penting
Floating IP tidak didukung pada konfigurasi IP sekunder NIC dalam skenario penyeimbangan beban. Untuk informasi selengkapnya, lihat Batasan Azure Load Balancer. Jika Anda memerlukan alamat IP lain untuk VM, sebarkan NIC kedua.
Catatan
Ketika VM tanpa alamat IP publik ditempatkan di kumpulan back-end instans internal (tanpa alamat IP publik) Azure Load Balancer Standar, tidak ada konektivitas internet keluar kecuali lebih banyak konfigurasi dilakukan untuk memungkinkan perutean ke titik akhir publik. Untuk informasi selengkapnya tentang cara mencapai konektivitas keluar, lihat Konektivitas titik akhir publik untuk VM menggunakan Azure Standard Load Balancer dalam skenario ketersediaan tinggi SAP.
Penting
Jangan aktifkan tanda waktu TCP pada VM Azure yang ditempatkan di belakang Azure Load Balancer. Mengaktifkan tanda waktu TCP dapat menyebabkan pemeriksaan kesehatan gagal. Atur parameter net.ipv4.tcp_timestamps ke 0. Untuk informasi selengkapnya, lihat Pemeriksaan kesehatan Azure Load Balancer.
[A] Tambahkan aturan firewall untuk port pemeriksan:
sudo firewall-cmd --add-port=<probe-port>/tcp --permanent
sudo firewall-cmd --reload
Membuat kluster Pacemaker
Untuk membuat kluster Pacemaker dasar untuk server IBM Db2 ini, lihat Menyiapkan Pacemaker di Red Hat Enterprise Linux di Azure.
Konfigurasi Pacemaker Db2
Saat menggunakan Pacemaker untuk failover otomatis jika terjadi kegagalan simpul, Anda perlu mengonfigurasi instans Db2 dan Pacemaker. Bagian ini akan menjelaskan jenis konfigurasi ini.
Item berikut diawali dengan:
- [A]: Berlaku untuk semua simpul
- [1]: Hanya berlaku untuk simpul 1
- [2]: Hanya berlaku untuk node 2
[A] Prasyarat untuk konfigurasi Pacemaker:
Matikan kedua server database dengan pengguna db2<sid> dengan db2stop.
Ubah lingkungan shell untuk pengguna db2<sid> menjadi /bin/ksh:
# Install korn shell: sudo yum install ksh # Change users shell: sudo usermod -s /bin/ksh db2<sid>
Konfigurasi Pacemaker
[1] Konfigurasi Pacemaker khusus IBM Db2 HADR:
# Put Pacemaker into maintenance mode sudo pcs property set maintenance-mode=true[1] Membuat sumber IBM Db2:
Jika membuat kluster di RHEL 7.x, pastikan untuk memperbarui agen sumber daya paket ke versi atau yang
resource-agents-4.1.1-61.el7_9.15lebih tinggi. Gunakan perintah berikut untuk membuat sumber daya kluster:# Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' master meta notify=true resource-stickiness=5000 #Configure resource stickiness and correct cluster notifications for master resoruce sudo pcs resource update Db2_HADR_ID2-master meta notify=true resource-stickiness=5000 # Configure virtual IP - same as Azure Load Balancer IP sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40' # Configure probe port for Azure load Balancer sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500 #Create a group for ip and Azure loadbalancer probe port sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2 #Create colocation constrain - keep Db2 HADR Master and Group on same node sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-master #Create start order constrain sudo pcs constraint order promote Db2_HADR_ID2-master then g_ipnc_db2id2_ID2Jika membuat kluster di RHEL 8.x, pastikan untuk memperbarui agen sumber daya paket ke versi atau yang
resource-agents-4.1.1-93.el8lebih tinggi. Untuk detailnya lihat Sumber daya Red Hat KBAdb2dengan HADR gagal dipromosikan dengan statusPRIMARY/REMOTE_CATCHUP_PENDING/CONNECTED. Gunakan perintah berikut untuk membuat sumber daya kluster:# Replace bold strings with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo pcs resource create Db2_HADR_ID2 db2 instance='db2id2' dblist='ID2' promotable meta notify=true resource-stickiness=5000 #Configure resource stickiness and correct cluster notifications for master resoruce sudo pcs resource update Db2_HADR_ID2-clone meta notify=true resource-stickiness=5000 # Configure virtual IP - same as Azure Load Balancer IP sudo pcs resource create vip_db2id2_ID2 IPaddr2 ip='10.100.0.40' # Configure probe port for Azure load Balancer sudo pcs resource create nc_db2id2_ID2 azure-lb port=62500 #Create a group for ip and Azure loadbalancer probe port sudo pcs resource group add g_ipnc_db2id2_ID2 vip_db2id2_ID2 nc_db2id2_ID2 #Create colocation constrain - keep Db2 HADR Master and Group on same node sudo pcs constraint colocation add g_ipnc_db2id2_ID2 with master Db2_HADR_ID2-clone #Create start order constrain sudo pcs constraint order promote Db2_HADR_ID2-clone then g_ipnc_db2id2_ID2[1] Memulai sumber daya IBM Db2:
Keluarkan Pacemaker dari mode pemeliharaan.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo pcs property set maintenance-mode=false[1] Pastikan status kluster baik-baik saja OKE dan semua sumber dimulai. Tidak penting di node mana sumber daya berjalan.
sudo pcs status 2 nodes configured 5 resources configured Online: [ az-idb01 az-idb02 ] Full list of resources: rsc_st_azure (stonith:fence_azure_arm): Started az-idb01 Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2] Masters: [ az-idb01 ] Slaves: [ az-idb02 ] Resource Group: g_ipnc_db2id2_ID2 vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01 nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01 Daemon Status: corosync: active/disabled pacemaker: active/disabled pcsd: active/enabled
Penting
Anda harus mengelola instans Db2 berkluster Pacemaker dengan menggunakan alat Pacemaker. Jika Anda menggunakan perintah db2 seperti db2stop, Pacemaker akan mendeteksi tindakan tersebut sebagai kegagalan sumber. Jika Anda melakukan pemeliharaan, Anda dapat memasukkan simpul atau sumber ke dalam mode pemeliharaan. Pacemaker menangguhkan sumber daya pemantauan, lalu Anda dapat menggunakan perintah administrasi db2 normal.
Buat perubahan pada profil SAP untuk menggunakan IP virtual agar tersambung
Untuk menyambungkan ke instans utama konfigurasi HADR, lapisan aplikasi SAP harus menggunakan alamat IP virtual yang ditentukan dan dikonfigurasi untuk Azure Load Balancer. Diperlukan perubahan berikut:
/sapmnt/<SID>/profile/DEFAULT.PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/<SID>/global/db6/db2cli.ini
Hostname=db-virt-hostname
Instal server aplikasi utama dan dialog
Saat Anda menginstal server aplikasi utama dan dialog terhadap konfigurasi Db2 HADR, gunakan nama host virtual yang Anda pilih untuk konfigurasi.
Jika Anda melakukan penginstalan sebelum membuat konfigurasi Db2 HADR, lakukan perubahan seperti yang dijelaskan di bagian sebelumnya dan sebagai berikut untuk SAP Java stack.
Pemeriksaan JDBC URL sistem ABAP+Java atau Java stack
Gunakan alat Konfigurasi J2EE untuk memeriksa atau memperbarui JDBC URL. Karena alat Konfigurasi J2EE merupakan alat grafis, Anda harus menginstal server X:
Masuk ke server aplikasi utama instans J2EE dan jalankan:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shDi bingkai sebelah kiri, pilih penyimpanan keamanan.
Di bingkai sebelah kanan, pilih
jdbc/pool/\<SAPSID>/urlkunci.Ubah nama host di URL JDBC menjadi nama host virtual.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Pilih Tambahkan.
Untuk menyimpan perubahan Anda, pilih ikon disk di kiri atas.
Tutup alat konfigurasi.
Mulai ulang instans Java.
Mengonfigurasi pengarsipan log untuk penyiapan HADR
Untuk mengonfigurasi pengarsipan log Db2 untuk setup HADR, sebaiknya Anda mengonfigurasi database utama dan siaga agar memiliki kemampuan pengambilan log otomatis dari semua lokasi arsip log. Baik database utama dan siaga harus dapat mengambil file arsip log dari semua lokasi arsip log yang salah satu instans database-nya mungkin mengarsipkan file log.
Pengarsipan log hanya dilakukan oleh database utama. Jika Anda mengubah peran HADR dari server database atau terjadi kegagalan, database utama baru bertanggung jawab untuk pengarsipan log. Jika Anda menyiapkan beberapa lokasi arsip log, log Anda mungkin akan diarsipkan dua kali. Jika terjadi catch-up lokal atau jarak jauh, Anda mungkin juga harus menyalin log yang diarsipkan secara manual dari server utama yang lama ke lokasi log aktif server utama yang baru.
Sebaiknya konfigurasikan pembagian NFS umum atau GlusterFS, di dengan log ditulis dari kedua simpul. Bagian NFS atau GlusterFS harus sangat tersedia.
Anda bisa menggunakan bagian NFS atau GlusterFS yang sangat tersedia untuk transport atau direktori profil. Untuk informasi selengkapnya, lihat:
- GlusterFS di Azure VM di Red Hat Enterprise Linux untuk SAP NetWeaver.
- Ketersediaan tinggi untuk SAP NetWeaver di Azure VM di Red Hat Enterprise Linux dengan Azure NetApp Files untuk Aplikasi SAP.
- Azure NetApp Files (untuk membuat berbagi NFS).
Menguji penyiapan kluster
Bagian ini menjelaskan cara menguji penyiapan Db2 HADR Anda. Setiap tes mengasumsikan IBM Db2 primer berjalan pada komputer virtual az-idb01. Pengguna dengan hak istimewa sudo atau root (tidak disarankan) harus digunakan.
Status awal untuk semua kasus pengujian dijelaskan di sini: (status crm_mon -r atau pcs)
- status pcs adalah rekam jepret status Pacemaker pada waktu eksekusi.
- crm_mon -r adalah output berkelanjutan dari status Pacemaker.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb01 ]
Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Status asli dalam sistem SAP didokumentasikan dalam Transaksi DBACOCKPIT > Konfigurasi > Ringkasan, seperti yang ditunjukkan pada gambar berikut:
Uji pengambilalihan IBM Db2
Penting
Sebelum memulai tes, pastikan:
Pacemaker tidak memiliki tindakan yang gagal (status pcs).
Tidak ada batasan lokasi (sisa pengujian migrasi).
Sinkronisasi IBM Db2 HADR berfungsi. Tanyakan kepada pengguna db2<sid>.
db2pd -hadr -db <DBSID>
Migrasikan simpul yang menjalankan database Db2 utama dengan melaksanakan perintah berikut:
# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
Begitu migrasi selesai, output status crm akan terlihat seperti:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Status asli dalam sistem SAP didokumentasikan dalam Transaksi DBACOCKPIT > Konfigurasi > Ringkasan, seperti yang ditunjukkan pada gambar berikut:
Migrasi sumber dengan "pemindahan sumber pcs" membuat batasan lokasi. Kendala lokasi dalam hal ini mencegah berjalannya instans IBM Db2 pada az-idb01. Jika batasan lokasi tidak dihapus, sumber daya tidak dapat gagal kembali.
Hapus batasan lokasi dan simpul siaga akan dimulai pada az-idb01.
# On RHEL 7.x
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource clear Db2_HADR_ID2-clone
Dan status kluster berubah menjadi:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb01
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Migrasikan sumber kembali ke az-idb01 dan bersihkan batasan lokasi
# On RHEL 7.x
sudo pcs resource move Db2_HADR_ID2-master az-idb01
sudo pcs resource clear Db2_HADR_ID2-master
# On RHEL 8.x
sudo pcs resource move Db2_HADR_ID2-clone --master
sudo pcs resource clear Db2_HADR_ID2-clone
- Pada RHEL 7.x -
pcs resource move <resource_name> <host>: Membuat batasan lokasi dan dapat menyebabkan masalah dengan pengambarapan - Pada RHEL 8.x -
pcs resource move <resource_name> --master: Membuat batasan lokasi dan dapat menyebabkan masalah dengan pengambarapan pcs resource clear <resource_name>: Menghapus batasan lokasipcs resource cleanup <resource_name>: Menghapus semua kesalahan sumber daya
Uji pengambilalihan manual
Anda bisa menguji pengambilalihan manual dengan menghentikan layanan Pacemaker di simpul idb01:
systemctl stop pacemaker
status pada az-ibdb02
2 nodes configured
5 resources configured
Node az-idb01: pending
Online: [ az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Setelah failover, Anda dapat memulai layanan lagi di az-idb01.
systemctl start pacemaker
Hentikan proses Db2 pada simpul yang menjalankan database utama HADR
#Kill main db2 process - db2sysc
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2ptr 34598 34596 8 14:21 ? 00:00:07 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 34598
Instans Db2 akan gagal, dan Pacemaker akan memindahkan master simpul dan melaporkan status berikut:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=49, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 09:57:35 2019', queued=0ms, exec=362ms
Pacemaker memulai ulang instans database utama Db2 pada simpul yang sama, atau gagal ke simpul yang menjalankan instans database sekunder dan kesalahan dilaporkan.
Hentikan proses Db2 pada simpul yang menjalankan instans database sekunder
[sapadmin@az-idb02 ~]$ sudo ps -ef|grep db2sysc
db2id2 23144 23142 2 09:53 ? 00:00:13 db2sysc 0
[sapadmin@az-idb02 ~]$ sudo kill -9 23144
Simpul masuk ke status gagal dan kesalahan dilaporkan.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb01 ]
Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01
Failed Actions:
* Db2_HADR_ID2_monitor_20000 on az-idb02 'not running' (7): call=144, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 10:02:09 2019', queued=0ms, exec=0ms
Instans Db2 akan dimulai ulang dalam peran sekunder yang telah ditetapkan sebelumnya.
Hentikan DB melalui db2stop force di simpul yang menjalankan instans database utama HADR
Saat pengguna db2<sid> menjalankan perintah db2stop force:
az-idb01:db2ptr> db2stop force
Kegagalan terdeteksi:
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Slaves: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Stopped
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Stopped
Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms
Instans database sekunder Db2 HADR dipromosikan menjadi peran utama.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Failed Actions:
* Db2_HADR_ID2_demote_0 on az-idb01 'unknown error' (1): call=110, status=complete, exitreason='none',
last-rc-change='Wed Jun 26 14:03:12 2019', queued=0ms, exec=355ms
Hentikan VM yang menjalankan instans database utama HADR dengan "hentikan"
#Linux kernel panic.
sudo echo b > /proc/sysrq-trigger
Dalam kasus seperti itu, Pacemaker mendeteksi bahwa simpul yang menjalankan instans database utama tidak merespons.
2 nodes configured
5 resources configured
Node az-idb01: UNCLEAN (online)
Online: [ az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb01 ]
Slaves: [ az-idb02 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb01
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb01
Langkah selanjutnya adalah memeriksa situasi Split brain. Setelah simpul yang bertahan menentukan bahwa node yang terakhir menjalankan instans database utama tidak berfungsi, failover sumber akan dijalankan.
2 nodes configured
5 resources configured
Online: [ az-idb02 ]
OFFLINE: [ az-idb01 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Stopped: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02
Jika terjadi kepanikan kernel, simpul yang gagal akan dimulai ulang oleh agen anggar. Setelah simpul yang gagal kembali online, Anda harus memulai kluster pacemaker dengan
sudo pcs cluster start
memulai instans Db2 ke peran sekunder.
2 nodes configured
5 resources configured
Online: [ az-idb01 az-idb02 ]
Full list of resources:
rsc_st_azure (stonith:fence_azure_arm): Started az-idb02
Master/Slave Set: Db2_HADR_ID2-master [Db2_HADR_ID2]
Masters: [ az-idb02 ]
Slaves: [ az-idb01 ]
Resource Group: g_ipnc_db2id2_ID2
vip_db2id2_ID2 (ocf::heartbeat:IPaddr2): Started az-idb02
nc_db2id2_ID2 (ocf::heartbeat:azure-lb): Started az-idb02