已知问题

本页面介绍在使用 SAP on Google Cloud 时可能遇到的已知问题。本页面仅包括 Cloud Customer Care 团队的 SAP 专家所关注的问题。

其他可能会影响 SAP 系统的问题可能会在其他 Google Cloud 产品和服务的文档中列出。例如，Compute Engine 已知问题页面中列出了与 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 横向扩容将会由于适用于 SAP HANA 的存储管理器中出现 Python 错误而发生故障。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 的问题，之所以在这里描述是因为它影响到 SAP on Google Cloud 用户。

解决方法

问题的解决方法因操作系统而异。

SUSE

SUSE 提供了 Corosync 维护更新来解决此问题。如需应用修复程序，请将您的 Corosync 软件更新为下表中列出的版本之一。

SUSE 版本 Corosync 版本
SLES 12 - 所有 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 提供了 Corosync 维护更新来解决此问题。如需应用修复程序，请将您的 Corosync 软件更新为下表中列出的版本之一。

Red Hat 版本 Corosync 版本
RHEL 7 corosync-2.4.5-7.el7_9.2
RHEL 8 corosync-3.1.5-2.el8

RHEL 上的 gVNIC 重置导致高可用性配置中的故障切换

如果您将 gVNIC 网络驱动程序与 8.7 之前的 RHEL 版本结合使用，则 gVNIC 可能会重置，导致相关虚拟机失去网络连接几秒钟，这可能造成高可用性集群中不必要的故障切换。

您可能会观察到操作系统的消息日志文件中会生成内核调用堆栈，例如：

  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 驱动程序的早期版本，该版本没有所需的增强功能和稳定性补丁程序。

解决方法

使用高于 8.7 的 SAP 认证的 RHEL 版本和 gVNIC 驱动程序。如果您使用的是 Compute Engine 中的第三代机器（例如 M3），则执行此操作尤为重要，因为它们不支持使用 VirtIO 驱动程序，因此要求您使用 gVNIC 驱动程序。如需查看默认使用 gVNIC 的机器类型的完整列表，请参阅机器系列比较表。