Bekannte Probleme

Auf dieser Seite werden bekannte Probleme beschrieben, die bei der Verwendung von SAP in Google Cloud auftreten können. Die Seite enthält nur die Probleme, die den SAP-Experten im Cloud Customer Care-Team gemeldet wurden.

Andere Probleme, die sich auf SAP-Systeme auswirken können, sind möglicherweise in der Dokumentation für andere Google Cloud-Produkte und -Dienste aufgeführt. Probleme, die sich beispielsweise auf Compute Engine-VMs, nichtflüchtige Speicher oder Betriebssystem-Images beziehen, werden auf der Seite Bekannte Probleme mit Compute Engine aufgeführt.

Änderungen an der Standard-Fencing-Methode können zu einer Fencing-Zeitüberschreitung in RHEL 8.4 führen

Wenn Sie RHEL 8.4 mit den Fencing-Agents fence-agents-gce-Versionen 4.2.1-65 auf 4.2.1-69 verwenden, kann eine Fencing-Zeitüberschreitung auftreten.

Der Fencing-Agent fence-agents-gce mit den Versionen 4.2.1-65 bis 4.2.1-69 definiert keine Standard-Fencing-Methode cycle. Daher wird die Standard-Fencing-Methode auf die Methode onoff zurückgesetzt. Dadurch führt der Fencing-Agent einen stop-API-Aufruf und einen start-API-Aufruf anstelle eines einzelnen reset-API-Aufrufs aus. Der Fencing-Prozess braucht länger, um auf die APIs zuzugreifen, was zu einer Fencing-Zeitüberschreitung führen kann.

Lösung

Versuchen Sie Folgendes, um dieses Problem zu beheben:

• Ändern Sie die Standard-Fencing-Methode mit dem folgenden Befehl in cycle:

  pcs resource update <STONITH_device_name> method=cycle
  

• Prüfen Sie Ihre fence-agents-gce-Version und achten Sie darauf, dass Sie die Version 4.2.1-70 oder höher verwenden:

  • Führen Sie den folgenden Befehl aus, um die Version des Fencing-Agents zu überprüfen:

  yum info fence-agents-gce
  

  • Führen Sie den folgenden Befehl aus, um Ihren Fencing-Agent zu aktualisieren:

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

StorageException für Cloud Storage kann zu einer beschädigten Backint-Agent-Sicherung führen

FIXED: Dieses Problem wurde behoben. Informationen zum Anwenden der Fehlerkorrektur und zum Prüfen, ob Sie betroffen sind, finden Sie auf dieser Seite unter Lösung.

Unter bestimmten Bedingungen kann ein Backint-Agent beim Auftreten einer StorageException während der Cloud Storage-Backint-Agent für SAP HANA eine Sicherung in Cloud Storage speichert, doppelte Daten an die Sicherungsdatei anhängen, wodurch die Sicherungsdatei nicht zur Wiederherstellung verwendbar ist.

Wenn Sie versuchen, die Datenbank aus einer Sicherungsdatei mit duplizierten Daten wiederherzustellen, erhalten Sie die folgende Fehlermeldung:

  exception 3020043: Wrong checksum

Betroffene Nutzer

SAP HANA-Nutzer, die den Cloud Storage Backint-Agent für SAP HANA verwenden, um Sicherungen in Cloud Storage zu speichern.

Lösung

Um dieses Problem zu beheben, installieren Sie zuerst Version 1.0.13 oder höher des Backint-Agents und prüfen Sie dann die Backint-Agent-Logs auf StorageException-Fehler, um festzustellen, ob Sie von diesem Problem betroffen sind.

Eine Anleitung zum Upgrade des Backint-Agents finden Sie unter Backint-Agent auf eine neue Version aktualisieren.

Um festzustellen, ob Sie von diesem Problem betroffen sind, sehen Sie in den Backint-Agent-Logs nach:

1. Suchen Sie als sidadm-Nutzer auf dem SAP HANA-Host in den Logs nach der Nachricht StorageException:

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

2. Wenn Sie die Fehlermeldung finden, prüfen Sie den Status der zugehörigen Sicherung:

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

   Ersetzen Sie im Beispiel die folgenden Platzhalterwerte:

   • EBID durch die externe Sicherungs-ID der Sicherung.
   • BACKUP_FILE_NAME durch den Dateinamen der Sicherungsdatei.

   Wenn der Fehler checksum auftritt, wenden Sie sich an Cloud Customer Care.

Neben der vorherigen Prüfung sollten Sie die folgenden Aktionen als Teil Ihres Sicherungsvorgangs ausführen, um dieses und andere Probleme zu erkennen, bevor Ihre Sicherungen benötigt werden:

• Führen Sie gemäß den von SAP empfohlenen Best Practices regelmäßig das SAP-Tool hdbbackupcheck für Sicherungen aus, um die logische Konsistenz zu prüfen. Weitere Informationen finden Sie im SAP-Hinweis 1869119.
• Testen Sie Ihre Notfallwiederherstellungsverfahren regelmäßig.

Die SAP HANA-Bereitstellung mit horizontaler Skalierung schlägt aufgrund eines Python-Fehlers fehl

Wenn Sie SAP HANA 2.0 SPS 5 Revision 56 oder höher für ein SAP HANA-System mit horizontaler Skalierung und automatischem Host-Failover installieren, schlägt die Bereitstellung von SAP HANA mit horizontaler Skalierung und automatischem Host-Failover aufgrund eines Python-Fehlers im Storage Manager für SAP HANA fehl. Die SAP HANA-Trace-Logdateien zeigen den folgenden Python-Fehler für diesen Fehler: failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'.

Lösung

Verwenden Sie Version 2.2 oder höher des Storage-Managers für SAP HANA. Version 2.2 unterstützt SAP HANA 2.0 SPS 5 Revision 56 und höher. Weitere Informationen zum Speichermanager für SAP HANA finden Sie unter Automatischer SAP HANA-Host-Failover in Google Cloud.

Problem mit Cluster-Failover mit Hochverfügbarkeit aufgrund einer Corosync-Kommunikationsverzögerung

Bei dem Hochverfügbarkeitscluster für SAP HANA in Google Cloud kann das Failover aufgrund einer vorübergehenden Verzögerung bei der Übertragung von Corosync-Nachrichten zwischen den Clusterknoten fälschlicherweise ausgelöst werden.

Dieses Problem tritt sowohl bei SUSE- als auch bei Red Hat-Hochverfügbarkeitsbereitstellungen von Linux auf.

Dieses Problem bezieht sich nicht nur auf Google Cloud, sondern wird hier beschrieben, da es sich auf SAP-Nutzer in Google Cloud auswirkt.

Lösung

Die Lösung des Problems hängt vom Betriebssystem ab.

SUSE

SUSE hat ein Corosync-Wartungsupdate bereitgestellt, das das Problem löst. Aktualisieren Sie Ihre Corosync-Software auf eine der in der folgenden Tabelle aufgeführten Versionen, um das Problem zu beheben.

Hinweis: Die Informationen in der folgenden Tabelle dienen Ihnen als Beispiel. Die verbindlichen Informationen finden Sie im SUSE-Wissensdatenbankartikel.

SUSE-Version	Corosync-Version
SLES 12 – alle SP-Versionen	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 hat ein Corosync-Wartungsupdate bereitgestellt, das das Problem löst. Aktualisieren Sie Ihre Corosync-Software auf eine der in der folgenden Tabelle aufgeführten Versionen, um das Problem zu beheben.

Hinweis: Die Informationen in der folgenden Tabelle dienen Ihnen als Beispiel. Die verbindlichen Informationen finden Sie im Red Hat-Wissensdatenbankartikel.

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

gVNIC- das Zurücksetzen unter RHEL führt zu einem Failover in der Hochverfügbarkeitskonfiguration

Wenn Sie den gVNIC-Netzwerktreiber in Kombination mit RHEL-Versionen vor 8.7 verwenden, kann es zu einem Zurücksetzen von gVNIC kommen. Dies führt dazu, dass die Netzwerkverbindung der betreffenden VM für einige Sekunden unterbrochen wird, was zu unerwünschten Failovers in Ihrem HA-Cluster führen kann.

In der Nachrichten-Logdatei des Betriebssystems wird möglicherweise ein Kernel-Aufrufstack generiert. Beispiel:

  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

Ursache

Die Ursache dieses Problems ist, dass RHEL-Versionen vor 8.7 einen früheren Build des gVNIC-Treibers enthalten, der nicht die erforderlichen Verbesserungen und Stabilitäts-Patches hat.

Lösung

Verwenden Sie in Kombination mit dem gVNIC-Treiber eine SAP-zertifizierte Version von RHEL ab 8.7. Dies ist besonders wichtig, wenn Sie eine Maschine der dritten Generation von Compute Engine verwenden, z. B. M3, da diese die Verwendung des VirtIO-Treibers nicht unterstützen. und Sie müssen den gVNIC-Treiber verwenden. Eine vollständige Liste der Maschinentypen, die standardmäßig gVNIC haben, finden Sie in der Tabelle Vergleich der Maschinenserien.