Bagikan melalui

Ketersediaan tinggi IBM Db2 LUW di Azure Virtual Machines di Red Hat Enterprise Linux Server

  • Artikel

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
Dokumentasi
SAP Community Wiki: memiliki semua Catatan SAP yang diperlukan untuk Linux
Panduan Perencanaan dan penerapan Azure Virtual Machines untuk SAP di Linux
Microsoft Azure Virtual Machines penyebaran untuk SAP di Linux (artikel ini)
Panduan Penggunaan sistem manajemen database (DBMS) Azure Virtual Machines untuk SAP di Linux
Beban kerja SAP pada perencanaan dan daftar periksa penggunaan Azure
Gambaran Umum tentang Add-On Ketersediaan Tinggi untuk Red Hat Enterprise Linux 7
Administrasi Add-On Ketersediaan Tinggi
Referensi Add-On Ketersediaan Tinggi
Kebijakan Dukungan untuk Kluster Ketersediaan Tinggi RHEL - Microsoft Azure Virtual Machines sebagai Anggota Kluster
Memasang dan Mengonfigurasikan Red Hat Enterprise Linux 7.4 (dan yang lebih baru) Ketersediaan Tinggi Kluster pada Microsoft Azure
Penyebaran DBMS IBM Db2 Azure Virtual Machines untuk beban kerja SAP
IBM Db2 HADR 11.1
IBM Db2 HADR 10.5
Kebijakan Dukungan untuk kluster Ketersediaan Tinggi RHEL - Manajemen IBM Db2 untuk Linux, Unix, dan Windows dalam kluster

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.

Gambaran umum ketersediaan tinggi IBM Db2

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 lingkungan penuh ketersediaan tinggi IBM DB2

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.

  1. Buat atau pilih grup sumber.
  2. Buat atau pilih jaringan virtual dan subnet.
  3. Pilih jenis penyebaran yang sesuai untuk komputer virtual SAP. Biasanya set skala komputer virtual dengan orkestrasi fleksibel.
  4. Buat Komputer Virtual 1.
    1. Gunakan Red Hat Enterprise Linux untuk gambar SAP di Azure Marketplace.
    2. Pilih set skala, zona ketersediaan, atau set ketersediaan yang dibuat di langkah 3.
  5. Buat Komputer Virtual 2.
    1. Gunakan Red Hat Enterprise Linux untuk gambar SAP di Azure Marketplace.
    2. Pilih set skala, zona ketersediaan, atau set ketersediaan yang dibuat di langkah 3 (bukan zona yang sama seperti pada langkah 4).
  6. 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. Definisi Port SAP SWPM

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. Opsi SAP SWPM - DB2 HA

Untuk menyiapkan server database Siaga dengan menggunakan prosedur salinan sistem homogen SAP, jalankan langkah-langkah berikut:

  1. Pilih opsi Salinan sistem>Sistem target>Terdistribusi>Instans database.
  2. Sebagai metode salin, pilih Sistem Homogen sehingga Anda dapat menggunakan cadangan untuk mengembalikan cadangan pada instans server siaga.
  3. 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:

  1. Konfigurasi IP Frontend: Buat IP front-end. Pilih jaringan virtual dan nama subnet yang sama dengan komputer virtual database Anda.
  2. Kumpulan Backend: Buat kumpulan back-end dan tambahkan VM database.
  3. 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.

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. [1] Konfigurasi Pacemaker khusus IBM Db2 HADR:

    # Put Pacemaker into maintenance mode
sudo pcs property set maintenance-mode=true

  2. [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.15 lebih 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_ID2

    Jika membuat kluster di RHEL 8.x, pastikan untuk memperbarui agen sumber daya paket ke versi atau yang resource-agents-4.1.1-93.el8 lebih tinggi. Untuk detailnya lihat Sumber daya Red Hat KBA db2 dengan HADR gagal dipromosikan dengan status PRIMARY/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

  3. [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

  4. [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:

  1. Masuk ke server aplikasi utama instans J2EE dan jalankan:

    sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh

  2. Di bingkai sebelah kiri, pilih penyimpanan keamanan.

  3. Di bingkai sebelah kanan, pilih jdbc/pool/\<SAPSID>/url kunci.

  4. Ubah nama host di URL JDBC menjadi nama host virtual.

    jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0

  5. Pilih Tambahkan.

  6. Untuk menyimpan perubahan Anda, pilih ikon disk di kiri atas.

  7. Tutup alat konfigurasi.

  8. 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:

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:

DBACockpit - Pramigrasi

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:

DBACockpit - Pascamigrasi

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

DBACockpit - Batas lokasi yang dihapus

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 lokasi
  • pcs 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

Langkah berikutnya