Halaman ini diterjemahkan oleh Cloud Translation API.

Masalah umum

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 pembatas default menjadi cycle menggunakan perintah berikut:
```
pcs resource update <STONITH_device_name> method=cycle
```
Periksa versi fence-agents-gce dan pastikan Anda menggunakan versi 4.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 Backint Cloud Storage 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`

Mereset gVNIC di RHEL menyebabkan failover dalam konfigurasi HA

Jika Anda menggunakan driver jaringan gVNIC yang dikombinasikan dengan versi RHEL sebelum 8.7, Anda mungkin mengalami reset gVNIC yang menyebabkan VM yang bersangkutan kehilangan konektivitas jaringan selama beberapa detik, yang dapat mengakibatkan failover yang tidak diinginkan di cluster HA Anda.

Anda mungkin mengamati stack panggilan kernel yang 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 versi RHEL sebelum 8.7 berisi build driver gVNIC versi sebelumnya yang tidak memiliki peningkatan dan patch stabilitas yang diperlukan.

Resolusi

Gunakan RHEL versi bersertifikasi SAP yang lebih baru dari 8.7, bersama dengan driver 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 mengetahui daftar lengkap jenis mesin yang ditetapkan secara default ke gVNIC, lihat tabel Perbandingan seri mesin.