Halaman ini menjelaskan masalah umum yang mungkin Anda alami saat menggunakan SAP di Google Cloud. Halaman ini hanya berisi masalah yang telah menjadi perhatian spesialis SAP di tim Cloud Customer Care.
Masalah lain yang dapat memengaruhi sistem SAP mungkin tercantum dalam dokumentasi untuk produk dan layanan Google Cloud lainnya. Misalnya, masalah yang terkait dengan VM Compute Engine, persistent disk, atau image OS, dicantumkan di halaman masalah umum Compute Engine.
Perubahan pada metode pagar default dapat menyebabkan waktu tunggu pagar di RHEL 8.4
Jika Anda menggunakan RHEL 8.4 dengan agen pagar fence-agents-gce
versi 4.2.1-65
hingga 4.2.1-69
, waktu tunggu pagar dapat terjadi.
Agen pagar fence-agents-gce
versi 4.2.1-65
hingga 4.2.1-69
, tidak
menentukan metode pagar default cycle
. Akibatnya, metode pagar default
kembali ke metode onoff
. Hal ini menyebabkan agen pagar melakukan
panggilan API stop
dan panggilan API start
, bukan satu panggilan API reset
.
Jadi, proses pemagaran memerlukan waktu lebih lama untuk mengakses API, yang dapat menyebabkan
waktu tunggu pagar.
Resolusi
Untuk mengatasi masalah ini, coba opsi berikut:
Ubah metode pembatasan default menjadi
cycle
menggunakan perintah berikut:pcs resource update <STONITH_device_name> method=cycle
Periksa versi
fence-agents-gce
dan pastikan Anda menggunakan versi4.2.1-70
atau yang lebih baru:- Untuk memeriksa versi agen pagar Anda, jalankan perintah berikut:
yum info fence-agents-gce
- Untuk memperbarui agen pagar, jalankan perintah berikut:
yum --releasever=8.6 update fence-agents-gce
StorageException untuk Cloud Storage dapat menyebabkan pencadangan agen Backint rusak
Dalam kondisi tertentu, jika StorageException terjadi saat agen Backint Cloud Storage untuk SAP HANA menyimpan cadangan di Cloud Storage, agen Backint mungkin menambahkan data duplikat ke file cadangan, sehingga membuat file cadangan tidak dapat digunakan untuk pemulihan.
Jika mencoba memulihkan database dari file cadangan dengan data duplikat, Anda akan menerima error berikut:
exception 3020043: Wrong checksum
Pengguna yang terpengaruh
Pengguna SAP HANA yang menggunakan agen Cloud Storage Backint untuk SAP HANA untuk menyimpan cadangan di Cloud Storage.
Resolusi
Untuk mengatasi masalah ini, instal agen Backint versi 1.0.13 atau yang lebih baru, lalu periksa log agen Backint untuk menemukan error StorageException apakah Anda terpengaruh oleh masalah ini.
Untuk mengetahui petunjuk cara mengupgrade agen Backint, lihat Memperbarui agen Backint ke versi baru
Untuk melihat apakah Anda terpengaruh oleh masalah ini, periksa log agen Backint:
Sebagai pengguna adm sid di host SAP HANA, telusuri pesan
StorageException
dalam log:grep 'com.google.cloud.storage.StorageException' \ /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/opt/backint/backint-gcs/logs/*.log.*
Jika Anda menemukan pesan error, verifikasi status cadangan yang terkait:
$ hdbbackupcheck -e <var>EBID</var> --backintParamFile /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/opt/backint/backint-gcs/parameters.txt /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/backint/DB_$SAPSYSTEMNAME/<var>BACKUP_FILE_NAME</var>
Dalam contoh, ganti nilai placeholder berikut:
- EBID dengan ID cadangan eksternal.
- BACKUP_FILE_NAME dengan nama file di file cadangan.
Jika Anda menerima error
checksum
, hubungi Cloud Customer Care.
Selain pemeriksaan sebelumnya, untuk mendeteksi hal ini dan masalah lainnya sebelum pencadangan diperlukan, lakukan tindakan berikut sebagai bagian rutin dari proses pencadangan Anda:
- Sesuai praktik terbaik yang direkomendasikan SAP, jalankan alat
hdbbackupcheck
SAP secara rutin terhadap cadangan untuk memverifikasi konsistensi logis. Untuk mengetahui informasi selengkapnya, lihat Catatan SAP 1869119. - Uji prosedur pemulihan dari bencana Anda secara teratur.
Deployment penyebaran skala SAP HANA gagal karena error Python
Jika Anda menginstal SAP HANA 2.0 SPS 5 Revisi 56 atau yang lebih baru untuk sistem penyebaran skala SAP HANA dengan failover otomatis host, penyebaran skala SAP HANA dengan deployment failover otomatis host akan gagal karena adanya error Python pada pengelola penyimpanan untuk SAP HANA.
File log rekaman aktivitas SAP HANA menampilkan error Python berikut untuk kegagalan ini:
failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'
.
Resolusi
Gunakan pengelola penyimpanan versi 2.2 atau yang lebih baru untuk SAP HANA. Versi 2.2 menambahkan dukungan untuk SAP HANA 2.0 SPS 5 Revisi 56 dan yang lebih baru. Untuk mengetahui informasi selengkapnya tentang pengelola penyimpanan untuk SAP HANA, lihat failover otomatis host SAP HANA di Google Cloud.
Masalah failover cluster ketersediaan tinggi karena penundaan komunikasi Corosync
Untuk cluster ketersediaan tinggi (HA) untuk SAP HANA di Google Cloud, failover dapat dipicu secara keliru karena adanya penundaan sementara dalam pengiriman pesan Corosync antara node cluster.
Masalah ini terjadi pada distribusi Linux ketersediaan tinggi SUSE dan Red Hat.
Masalah ini tidak spesifik untuk Google Cloud, tetapi akan dijelaskan di sini karena telah memengaruhi SAP pada pengguna Google Cloud.
Resolusi
Penyelesaian masalah berbeda-beda, tergantung sistem operasi Anda.
SUSE
SUSE menyediakan pembaruan pemeliharaan Corosync yang memecahkan masalah. Untuk menerapkan perbaikan, update software Corosync Anda ke salah satu versi yang tercantum dalam tabel berikut.
Versi SUSE | Versi Corosync |
---|---|
SLES 12 - semua rilis SP | corosync-2.3.6-9.19.1 |
SLES 15 | corosync-2.4.5-5.13.1 |
SLES 15 SP1 | corosync-2.4.5-9.16.1 |
SLES 15 SP2 | corosync-2.4.5-10.14.6.1 |
SLES 15 SP3 | corosync-2.4.5-12.3.1 |
SLES 15 SP4 | corosync-2.4.5-12.7.1 |
Red Hat
Red Hat menyediakan update pemeliharaan Corosync yang memecahkan masalah. Untuk menerapkan perbaikan, update software Corosync Anda ke salah satu versi yang tercantum dalam tabel berikut.
Versi Red Hat | Versi Corosync |
---|---|
RHEL 7 | corosync-2.4.5-7.el7_9.2 |
RHEL 8 | corosync-3.1.5-2.el8 |
Reset gVNIC pada RHEL menyebabkan failover dalam konfigurasi HA
Jika Anda menggunakan driver jaringan gVNIC bersama dengan versi RHEL sebelum 8.7, Anda mungkin akan mengalami reset gVNIC yang menyebabkan VM terkait kehilangan konektivitas jaringan selama beberapa detik, yang dapat mengakibatkan failover yang tidak diinginkan di cluster HA Anda.
Anda mungkin melihat stack panggilan kernel dihasilkan dalam file log pesan OS, misalnya:
Feb 4 06:58:33 kernel: ------------[ cut here ]------------
Feb 4 06:58:33 kernel: NETDEV WATCHDOG: eth0 (gvnic): transmit queue 0 timed out
Feb 4 06:58:33 kernel: WARNING: CPU: 51 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x272/0x280
Feb 4 06:58:33 kernel: Modules linked in: falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) falcon_kal(E) falcon_lsm_pinned_16206(E) binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set falcon_lsm_pinned_16108(E) nf_tables nfnetlink intel_rapl_msr intel_rapl_common nfit libnvdimm vfat fat dm_mod gve crct10dif_pclmul crc32_pclmul i2c_piix4 ghash_clmulni_intel rapl pcspkr auth_rpcgss sunrpc xfs libcrc32c crc32c_intel serio_raw nvme nvme_core t10_pi [last unloaded: falcon_kal]
Feb 4 06:58:33 kernel: CPU: 51 PID: 0 Comm: swapper/51 Kdump: loaded Tainted: P E --------- - - 4.18.0-305.82.1.el8_4.x86_64 #1
Feb 4 06:58:33 kernel: Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/13/2023
Feb 4 06:58:33 kernel: RIP: 0010:dev_watchdog+0x272/0x280
...
Feb 4 06:58:33 kernel: ---[ end trace d6c7c7cb653cce9a ]---
Feb 4 06:58:33 kernel: gvnic 0000:00:03.0: Performing reset
Penyebab
Penyebab masalah ini adalah bahwa versi RHEL sebelum 8.7 berisi {i>build<i} dari {i>driver<i} gVNIC yang tidak memiliki penyempurnaan yang diperlukan dan patch stabilitas.
Resolusi
Menggunakan versi RHEL bersertifikasi SAP yang lebih baru dari 8.7, dikombinasikan dengan {i>driver<i} gVNIC. Tindakan ini sangat penting jika Anda menggunakan mesin generasi ketiga dari Compute Engine, seperti M3, karena tidak mendukung penggunaan driver VirtIO, sehingga Anda harus menggunakan driver gVNIC. Untuk daftar lengkap jenis mesin yang ditetapkan secara default ke gVNIC, lihat Rangkaian mesin perbandingan dengan Google.