Bagikan melalui

Ketersediaan tinggi IBM Db2 LUW di Azure VM di SUSE Linux Enterprise Server dengan Pacemaker

  • 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
1984787 SUSE LINUX Enterprise Server 12: Catatan pemasangan
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
Panduan praktik terbaik SUSE Linux Enterprise Server untuk Aplikasi SAP 12 SP4
Ekstensi Ketersediaan Tinggi SUSE Linux Enterprise 12 SP4
Penyebaran DBMS IBM Db2 Azure Virtual Machines untuk beban kerja SAP
IBM Db2 HADR 11.1
IBM Db2 HADR R 10.5

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 SUSE Linux dan konfigurasikan sistem file.
  • Instal dan konfigurasikan Pacemaker.
  • Instal NFS yang sangat tersedia.
  • 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 yang digunakan untuk koneksi server aplikasi SAP. db-virt-hostname, db-virt-ip.
Fencing Azure Fencing Azure atau fencing SBD (sangat disarankan). Metode untuk menghindari situasi split brain.
SBD VM Penyimpanan, jaringan, ukuran komputer virtual SBD.
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 SUSE Linux Enterprise Server di Azure.

Penting

Untuk Db2 versi 11.5.6 dan yang lebih tinggi, sebaiknya gunakan Solusi terintegrasi menggunakan Pacemaker dari IBM.

Penyebaran di SUSE Linux

Agen sumber daya untuk IBM Db2 LUW termasuk dalam SUSE Linux Enterprise Server untuk Aplikasi SAP. Untuk penyiapan yang dijelaskan dalam dokumen ini, Anda harus menggunakan SUSE Linux Server untuk Aplikasi SAP. Azure Marketplace berisi gambar untuk SUSE Enterprise Server untuk Aplikasi SAP 12 yang dapat Anda gunakan untuk menyebarkan komputer virtual baru. Perhatikan berbagai model dukungan atau layanan yang ditawarkan oleh SUSE 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 SLES 12 SP4 karena tersedia peningkatan performa terkait Azure dalam versi SUSE 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 gambar SLES untuk 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 gambar SLES untuk 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 for Linux, Unix, dan Windows"
  • Filter tambahan untuk versi SAP NetWeaver, konfigurasi stack, atau sistem operasi

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. Ini harus berupa nomor port yang sama untuk kedua instans database Definisi Port SAP SWPM

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.

  4. Siapkan HADR untuk IBM Db2.

    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.

Saat Anda menggunakan perangkat SBD untuk Linux Pacemaker, atur parameter Db2 HADR berikut:

  • Durasi jendela peer HADR (detik) (HADR_PEER_WINDOW) = 300
  • Nilai batas waktu HADR (HADR_TIMEOUT) = 60

Saat Anda menggunakan agen fencing Azure Pacemaker, atur parameter berikut:

  • Durasi jendela peer HADR (detik) (HADR_PEER_WINDOW) = 900
  • Nilai batas waktu HADR (HADR_TIMEOUT) = 60

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.

Penting

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.

Untuk tujuan demonstrasi dan prosedur yang dijelaskan dalam artikel ini, database SID adalah PTR.

Pemeriksaan IBM Db2 HADR

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 PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
# 
#                             HADR_ROLE = PRIMARY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 1
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6137
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 13
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
#        STANDBY_RECV_REPLAY_GAP(bytes) = 0
#                      PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#                      STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
#              READS_ON_STANDBY_ENABLED = N

#Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
# 
#                             HADR_ROLE = STANDBY
#                           REPLAY_TYPE = PHYSICAL
#                         HADR_SYNCMODE = NEARSYNC
#                            STANDBY_ID = 0
#                         LOG_STREAM_ID = 0
#                            HADR_STATE = PEER
#                            HADR_FLAGS = TCP_PROTOCOL
#                   PRIMARY_MEMBER_HOST = azibmdb02
#                      PRIMARY_INSTANCE = db2ptr
#                        PRIMARY_MEMBER = 0
#                   STANDBY_MEMBER_HOST = azibmdb01
#                      STANDBY_INSTANCE = db2ptr
#                        STANDBY_MEMBER = 0
#                   HADR_CONNECT_STATUS = CONNECTED
#              HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
#           HEARTBEAT_INTERVAL(seconds) = 15
#                      HEARTBEAT_MISSED = 0
#                    HEARTBEAT_EXPECTED = 6186
#                 HADR_TIMEOUT(seconds) = 60
#         TIME_SINCE_LAST_RECV(seconds) = 5
#              PEER_WAIT_LIMIT(seconds) = 0
#            LOG_HADR_WAIT_CUR(seconds) = 0.000
#     LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
#    LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
#                   LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
#             PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#             STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#                   HADR_LOG_GAP(bytes) = 0
#      STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
#        STANDBY_RECV_REPLAY_GAP(bytes) = 155
#                      PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#                      STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#               STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
#          STANDBY_RECV_BUF_SIZE(pages) = 2048
#              STANDBY_RECV_BUF_PERCENT = 0
#            STANDBY_SPOOL_LIMIT(pages) = 0
#                 STANDBY_SPOOL_PERCENT = NULL
#                    STANDBY_ERROR_TIME = NULL
#                  PEER_WINDOW(seconds) = 300
#                       PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
#              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.

Membuat kluster Pacemaker

Untuk membuat kluster Pacemaker dasar untuk server IBM Db2 ini, lihat Menyiapkan Pacemaker di SUSE Linux Enterprise Server 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. Sebaiknya Anda menggunakan alat Yast.

Konfigurasi Pacemaker

Penting

Pengujian terbaru mengungkapkan situasi di mana netcat berhenti merespons permintaan karena backlog dan keterbatasannya dalam menangani satu koneksi saja. Sumber daya netcat berhenti mendengarkan permintaan Azure Load Balancer dan IP floating menjadi tidak tersedia. Untuk kluster Pacemaker yang ada, kami pernah menyarankan untuk mengganti netcat dengan socat. Saat ini kami menyarankan untuk menggunakan agen sumber daya azure-lb yang merupakan bagian dari agen sumber daya paket dengan persyaratan versi paket berikut:

  • Untuk SLES 12 SP4/SP5, versi setidaknya harus resource-agents-4.3.018.a7fb5035-3.30.1.
  • Untuk SLES 15/15 SP1, versi harus setidaknya agen sumber daya-4.3.0184.6ee15eb2-4.13.1.

Perhatikan bahwa perubahan akan memerlukan waktu henti singkat.
Untuk kluster Pacemaker yang ada, jika konfigurasi sudah diubah untuk menggunakan socat seperti yang dijelaskan di Azure Load-Balancer Deteksi Pengerasan, tidak ada persyaratan untuk segera beralih ke agen sumber daya azure-lb.

  1. [1] Konfigurasi Pacemaker khusus IBM Db2 HADR:

    # Put Pacemaker into maintenance mode
sudo crm configure property maintenance-mode=true

  2. [1] Membuat sumber IBM Db2:

    # Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer.
sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \
        params instance="db2ptr" dblist="PTR" \
        op start interval="0" timeout="130" \
        op stop interval="0" timeout="120" \
        op promote interval="0" timeout="120" \
        op demote interval="0" timeout="120" \
        op monitor interval="30" timeout="60" \
        op monitor interval="31" role="Master" timeout="60"

# Configure virtual IP - same as Azure Load Balancer IP
sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \
        op monitor interval="10s" timeout="20s" \
        params ip="10.100.0.10"

# Configure probe port for Azure load Balancer
sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \
        op monitor timeout=20s interval=10

sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR

sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \
        meta target-role="Started" notify="true"

sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master

sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start

sudo crm configure rsc_defaults resource-stickiness=1000
sudo crm configure rsc_defaults migration-threshold=5000

  3. [1] Memulai sumber daya IBM Db2:

    Keluarkan Pacemaker dari mode pemeliharaan.

    # Put Pacemaker out of maintenance-mode - that start IBM Db2
sudo crm configure property 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 crm status

# 2 nodes configured
# 5 resources configured

# Online: [ azibmdb01 azibmdb02 ]

# Full list of resources:

# stonith-sbd    (stonith:external/sbd): Started azibmdb02
# Resource Group: g_ip_db2ptr_PTR
#      rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
#      rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
# Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
#      Masters: [ azibmdb02 ]
#      Slaves: [ azibmdb01 ]

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 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 kanan, pilih kunci jdbc/pool/<SAPSID>/url.

  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 dengan log ditulis dari kedua node. Pembagian NFS harus sangat tersedia.

Anda bisa menggunakan pembagian NFS yang sangat tersedia untuk transportasi atau direktori profil. Untuk informasi selengkapnya, lihat:

Menguji penyiapan kluster

Bagian ini menjelaskan cara menguji penyiapan Db2 HADR Anda. Setiap pengujian mengasumsikan bahwa Anda masuk sebagai akar pengguna dan utama IBM Db2 berjalan pada komputer virtual azibmdb01 .

Status awal untuk semua kasus pengujian akan dijelaskan di sini: (status crm_mon -r atau crm)

  • status crm adalah rekam jepret status Pacemaker pada waktu eksekusi.
  • crm_mon -r adalah output berkelanjutan dari status Pacemaker.
2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   Promoting azibmdb01
     Slaves: [ azibmdb02 ]

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 crm).

  • Tidak ada batasan lokasi (sisa pengujian migrasi.

  • Sinkronisasi IBM Db2 HADR berfungsi. Periksa dengan pengguna db2<sid>

    db2pd -hadr -db <DBSID>

Migrasikan simpul yang menjalankan database Db2 utama dengan melaksanakan perintah berikut:

crm resource migrate msl_Db2_db2ptr_PTR azibmdb02

Begitu migrasi selesai, output status crm akan terlihat seperti:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

Status asli dalam sistem SAP didokumentasikan dalam Transaksi DBACOCKPIT > Konfigurasi > Ringkasan, seperti yang ditunjukkan pada gambar berikut:

DBACockpit - Pascamigrasi

Migrasi sumber daya dengan "migrasi sumber daya crm" membuat batasan lokasi. Batasan lokasi harus dihapus. Jika batasan lokasi tidak dihapus, sumber daya tidak dapat gagal kembali atau Anda dapat mengalami pengalihan yang tidak diinginkan.

Memigrasikan sumber daya kembali ke azibmdb01 dan menghapus batasan lokasi

crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
  • crm resource migrate <res_name><host>: Membuat batasan lokasi dan dapat menyebabkan masalah dengan pengambilalihan
  • pcs resource clear <res_name>: Membersihkan batasan lokasi
  • pcs resource cleanup <res_name>: Membersihkan semua kesalahan sumber daya

Menguji anggar SBD

Dalam hal ini, kami menguji fencing SBD, yang sebaiknya dilakukan saat Anda menggunakan SUSE Linux.

azibmdb01:~ # ps -ef|grep sbd
root       2374      1  0 Feb05 ?        00:00:17 sbd: inquisitor
root       2378   2374  0 Feb05 ?        00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root       2379   2374  0 Feb05 ?        00:01:51 sbd: watcher: Pacemaker
root       2380   2374  0 Feb05 ?        00:00:18 sbd: watcher: Cluster

azibmdb01:~ # kill -9 2374

Node kluster azibmdb01 harus di-boot ulang. Peran HADR utama IBM Db2 akan dipindahkan ke azibmdb02. Saat azibmdb01 kembali online, instans Db2 akan dipindahkan ke dalam peran instans database sekunder.

Jika layanan Pacemaker tidak dimulai otomatis pada primer sebelumnya yang di-boot ulang, pastikan untuk memulainya secara manual dengan:

sudo service pacemaker start

Uji pengambilalihan manual

Anda bisa menguji ambil alih manual dengan menghentikan layanan Pacemaker di node azibmdb01:

service pacemaker stop

status di azibmdb02

2 nodes configured
5 resources configured

Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Setelah failover, Anda dapat memulai layanan lagi di azibmdb01.

service pacemaker start

Hentikan proses Db2 pada simpul yang menjalankan database utama HADR

#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr    34598  34596  8 14:21 ?        00:00:07 db2sysc 0

azibmdb01:~ # kill -9 34598

Instans Db2 akan gagal, dan Pacemaker akan melaporkan status berikut:

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Slaves: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

Pacemaker memulai ulang instans database utama Db2 pada simpul yang sama, atau gagal ke simpul yang menjalankan instans database sekunder dan kesalahan dilaporkan.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms

Hentikan proses Db2 pada simpul yang menjalankan instans database sekunder

azibmdb02:~ # ps -ef|grep db2s
db2ptr    65250  65248  0 Feb11 ?        00:09:27 db2sysc 0

azibmdb02:~ # kill -9

Simpul dinyatakan mengalami kegagalan dan kesalahan dilaporkan

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb02
     Masters: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

Instans Db2 akan dimulai ulang dalam peran sekunder yang telah ditetapkan sebelumnya.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms

Hentikan DB melalui db2stop force di simpul yang menjalankan instans database utama HADR

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Saat pengguna db2<sid> menjalankan perintah db2stop force:

azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force

Kegagalan terdeteksi

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd    (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Stopped
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     rsc_Db2_db2ptr_PTR      (ocf::heartbeat:db2):   FAILED azibmdb01
     Slaves: [ azibmdb02 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms

Instans database sekunder Db2 HADR dipromosikan menjadi peran utama.

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
    last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms

Hentikan VM dengan mulai ulang di node yang menjalankan instans database utama HADR

#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger

Pacemaker mempromosikan instans sekunder ke peran instans utama. Instans utama lama akan berpindah ke peran sekunder setelah VM dan semua layanan dipulihkan sepenuhnya setelah reboot VM.

nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

Hentikan VM yang menjalankan instans database utama HADR dengan "hentikan"

#Linux kernel panic - halts OS
azibmdb01:~ # 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 azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb01
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb01 ]
     Slaves: [ azibmdb02 ]

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: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Stopped: [ azibmdb01 ]

Jika terjadi "penghentian" node, node yang gagal harus dimulai ulang melalui alat Manajemen Azure (di portal Azure, PowerShell, atau Azure CLI). Begitu node yang gagal kembali online, ia akan memulai instans Db2 ke peran sekunder.

2 nodes configured
5 resources configured

Online: [ azibmdb01 azibmdb02 ]

Full list of resources:

stonith-sbd     (stonith:external/sbd): Started azibmdb02
 Resource Group: g_ip_db2ptr_PTR
     rsc_ip_db2ptr_PTR  (ocf::heartbeat:IPaddr2):       Started azibmdb02
     rsc_nc_db2ptr_PTR  (ocf::heartbeat:azure-lb):      Started azibmdb02
 Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
     Masters: [ azibmdb02 ]
     Slaves: [ azibmdb01 ]

Langkah berikutnya