已知問題

本頁面說明您在 Google Cloud上使用 SAP 時可能遇到的已知問題。這個頁面只包含 Cloud Customer Care 團隊 SAP 專家注意到的問題。

其他可能影響 SAP 系統的問題，可能會列在其他 Google Cloud 產品和服務的說明文件中。舉例來說，與 Compute Engine VM、永久磁碟或 OS 映像檔相關的問題，會列在 Compute Engine 已知問題頁面中。

變更預設的圍欄方法可能會導致 RHEL 8.4 中的圍欄逾時

如果您使用 RHEL 8.4 搭配 fence-agents-gce 版本的圍欄代理程式 4.2.1-65 至 4.2.1-69，則可能會發生圍欄逾時。

圍欄代理程式 fence-agents-gce 版本 4.2.1-65 至 4.2.1-69 並未定義預設的圍欄方法 cycle。因此，預設的圍欄方法會改回 onoff 方法。這會導致圍欄代理程式發出 stop API 呼叫和 start API 呼叫，而不是單一 reset API 呼叫。因此，圍欄程序需要較長的時間才能存取 API，這可能會導致圍欄逾時。

解決方法

如要解決這個問題，請嘗試下列選項：

• 使用下列指令將預設的圍欄方法變更為 cycle：

  pcs resource update <STONITH_device_name> method=cycle
  

• 請檢查 fence-agents-gce 版本，並確認您使用的是 4.2.1-70 以上版本：

  • 如要檢查圍欄代理程式版本，請執行下列指令：

  yum info fence-agents-gce
  

  • 如要更新圍欄代理程式，請執行下列指令：

  yum --releasever=8.6 update fence-agents-gce
  

Cloud Storage 的 StorageException 可能會導致 Backint 代理程式備份損毀

在特定情況下，如果 SAP HANA 適用的 Cloud Storage Backint 代理程式在 Cloud Storage 中儲存備份時發生 StorageException，Backint 代理程式可能會在備份檔案中附加重複資料，導致備份檔案無法用於復原。

如果您嘗試從備份檔案復原資料庫，但備份檔案含有重複資料，系統會傳回以下錯誤：

  exception 3020043: Wrong checksum

受影響的使用者數

使用 SAP HANA 適用的 Cloud Storage Backint 代理程式，將備份儲存在 Cloud Storage 中的 SAP HANA 使用者。

解決方法

如要解決這個問題，請先安裝 Backint 代理程式 1.0.13 以上版本，然後檢查 Backint 代理程式記錄檔，看看是否有任何 StorageException 錯誤，以便瞭解您是否受到這個問題的影響。

如需升級 Backint 代理程式的操作說明，請參閱「將 Backint 代理程式更新為新版本」一文

如要瞭解是否受到這項問題影響，請檢查 Backint 代理程式記錄：

1. 以 SAP HANA 主機上的 sidadm 使用者身分，搜尋記錄中的 StorageException 訊息：

   grep 'com.google.cloud.storage.StorageException' \
    /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/opt/backint/backint-gcs/logs/*.log.*
   

2. 如果看到錯誤訊息，請確認相關聯的備份狀態：

   $ 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>
   

   在範例中，請替換下列預留位置值：

   • EBID 與備份的外部備份 ID。
   • BACKUP_FILE_NAME 與備份檔案的檔案名稱。

   如果您收到 checksum 錯誤，請與 Cloud Customer Care 團隊聯絡。

除了上述檢查項目外，您還可以透過下列動作，在需要備份前偵測這類問題和其他問題：

• 根據 SAP 建議的最佳做法，請定期對備份執行 SAP hdbbackupcheck 工具，以驗證邏輯一致性。詳情請參閱 SAP 注意事項 1869119。
• 定期測試災難復原程序。

因 Python 錯誤導致 SAP HANA 向外擴充部署失敗

如果您為具有主機自動容錯移轉功能的 SAP HANA 向外擴充系統安裝 SAP HANA 2.0 SPS 5 修訂版本 56 以上版本，由於 SAP HANA 儲存空間管理員中的 Python 發生錯誤，因此 SAP HANA 會以主機自動容錯移轉部署失敗。SAP HANA 追蹤記錄檔顯示此失敗的 Python 錯誤為：failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'。

解決方法

請使用 SAP HANA 適用的儲存空間管理工具 2.2 以上版本。2.2 版新增 SAP HANA 2.0 SPS 5 修訂版本 56 以上的支援。如要進一步瞭解 SAP HANA 的儲存空間管理工具，請參閱「 Google Cloud上的 SAP HANA 主機自動容錯移轉」。

由於 Corosync 通訊延遲，導致高可用性叢集發生容錯問題

針對 Google Cloud上的 SAP HANA 高可用性 (HA) 叢集，由於叢集節點之間的 Corosync 訊息傳輸會暫時延遲，因此可能會誤觸發備援機制。

這個問題會發生在 SUSE 和 Red Hat 高可用性 Linux 發行版上。

這項問題並非特定於 Google Cloud，但由於它影響了 Google Cloud 使用者的 SAP，因此我們在此說明。

解決方法

解決問題的方式會因作業系統而異。

SUSE

SUSE 提供的 Corosync 維護更新可解決這個問題。如要套用修正程式，請將 Corosync 軟體更新至下表列出的其中一個版本。

Red Hat

Red Hat 提供的 Corosync 維護更新可解決這個問題。如要套用修正程式，請將 Corosync 軟體更新至下表列出的其中一個版本。

RHEL 上的 gVNIC 重設會導致 HA 設定中發生故障切換

如果您使用 gVNIC 網路驅動程式搭配 8.7 之前的 RHEL 版本，可能會遇到 gVNIC 重設問題，導致相關的 VM 在幾秒內失去網路連線，進而導致 HA 叢集中發生不必要的備援。

您可能會在 OS 的訊息記錄檔中，看到產生的核心呼叫堆疊，例如：

  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

原因

發生這個問題的原因是，8.7 之前的 RHEL 版本包含較早版本的 gVNIC 驅動程式，而該版本沒有必要的強化功能和穩定性修補程式。

解決方法

請使用 SAP 認證的 RHEL 版本 (版本號碼大於 8.7)，並搭配 gVNIC 驅動程式。如果您使用的是 Compute Engine 第三代機器 (例如 M3)，這項操作就特別重要，因為這些機器不支援使用 VirtIO 驅動程式，因此您必須使用 gVNIC 驅動程式。如需預設為 gVNIC 的完整機器類型清單，請參閱機器系列比較表格。