Problemi noti

Questa pagina descrive i problemi noti che potresti riscontrare durante l'utilizzo di SAP su Google Cloud. La pagina include solo i problemi che sono stati sottoposti all'attenzione degli esperti SAP del team dell'assistenza clienti Google Cloud.

Altri problemi che possono influire sui sistemi SAP potrebbero essere elencati nella documentazione di altri prodotti e servizi Google Cloud. Ad esempio, i problemi correlati alle VM, ai dischi permanenti o alle immagini del sistema operativo di Compute Engine sono elencati nella pagina dei problemi noti di Compute Engine.

Le modifiche al metodo di recinzione predefinito possono causare il timeout della recinzione in RHEL 8.4

Se utilizzi RHEL 8.4 con l'agente di recinzione nelle versioni fence-agents-gce 4.2.1-65 a 4.2.1-69, potrebbe verificarsi un timeout del recinto virtuale.

Le versioni fence-agents-gce dell'agente di recinzione 4.2.1-65 a 4.2.1-69 non definiscono il metodo di recinzione predefinito cycle. Di conseguenza, il metodo di recinzione predefinito fa ricorso al metodo onoff. Di conseguenza, l'agente di recinzione effettua una chiamata API stop e una chiamata API start anziché una singola chiamata API reset. Di conseguenza, la procedura di recinzione richiede più tempo per accedere alle API, il che può comportare un timeout della recinzione.

Risoluzione

Per risolvere il problema, prova le seguenti opzioni:

• Modifica il metodo di recinzione predefinito in cycle utilizzando il seguente comando:

  pcs resource update <STONITH_device_name> method=cycle
  

• Controlla la versione di fence-agents-gce e assicurati di utilizzare la versione 4.2.1-70 o successiva:

  • Per controllare la versione dell'agente di recinzione, esegui il seguente comando:

  yum info fence-agents-gce
  

  • Per aggiornare l'agente di recinzione, esegui il seguente comando:

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

StorageException per Cloud Storage può causare il danneggiamento del backup dell'agente Backint

RISOLTO: il problema è stato risolto. Per informazioni su come applicare la correzione e verificare se il problema ti riguarda, consulta la sezione Risoluzione in questa pagina.

In determinate condizioni, se si verifica un'eccezione Storage quando l'agente Backint di Cloud Storage per SAP HANA archivia un backup in Cloud Storage, l'agente Backint potrebbe aggiungere dati duplicati al file di backup, rendendolo inutilizzabile per il recupero.

Se provi a recuperare il database da un file di backup con dati duplicati, viene visualizzato il seguente errore:

  exception 3020043: Wrong checksum

Utenti interessati

Utenti SAP HANA che utilizzano l'agente Backint di Cloud Storage per SAP HANA per archiviare i backup in Cloud Storage.

Risoluzione

Per risolvere il problema, installa innanzitutto la versione 1.0.13 o successive dell'agente Backint, quindi controlla i relativi log per verificare la presenza di errori StorageException per capire se il problema ti riguarda.

Per istruzioni sull'upgrade dell'agente Backint, consulta Aggiornare l'agente Backint a una nuova versione

Per verificare se il problema ti riguarda, controlla i log dell'agente Backint:

1. Come utente sidadm sull'host SAP HANA, cerca il messaggio StorageException nei log:

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

2. Se trovi il messaggio di errore, verifica lo stato del backup associato:

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

   Nell'esempio, sostituisci i seguenti valori segnaposto:

   • EBID con l'ID backup esterno del backup.
   • BACKUP_FILE_NAME con il nome del file di backup.

   Se ricevi un errore checksum, contatta l'assistenza clienti Google Cloud.

Oltre al controllo precedente, per rilevare questo e altri problemi prima che siano necessari i backup, includi le seguenti azioni nella procedura di backup:

• In base alle best practice consigliate da SAP, esegui regolarmente lo strumento SAP hdbbackupcheck sui backup per verificare la coerenza logica. Per ulteriori informazioni, consulta la nota SAP 1869119.
• Testa regolarmente le procedure di ripristino di emergenza.

Il deployment di SAP HANA su più nodi non riesce a causa di un errore Python

Se stai installando SAP HANA 2.0 SPS 5 Revisione 56 o versioni successive per un sistema SAP HANA scalabile orizzontalmente con failover automatico dell'host, il deployment di SAP HANA scalabile orizzontalmente con failover automatico dell'host non riesce a causa di un errore Python nello Gestione archiviazione per SAP HANA. I file di log traccia di SAP HANA mostrano il seguente errore Python per questo errore: failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'.

Risoluzione

Utilizza la versione 2.2 o successiva di Gestione archiviazione per SAP HANA. La versione 2.2 aggiunge il supporto per SAP HANA 2.0 SPS 5 Revision 56 e versioni successive. Per ulteriori informazioni su Gestione archiviazione per SAP HANA, consulta Failover automatico dell'host SAP HANA su Google Cloud.

Problema di failover del cluster ad alta disponibilità a causa di un ritardo nella comunicazione di Corosync

Per il cluster ad alta disponibilità (HA) per SAP HANA su Google Cloud, il failover può essere attivato erroneamente a causa di un ritardo temporaneo nella trasmissione dei messaggi Corosync tra i nodi del cluster.

Questo problema si verifica nelle distribuzioni Linux ad alta disponibilità SUSE e Red Hat.

Questo problema non è specifico di Google Cloud, ma è descritto qui perché ha interessato gli utenti di SAP su Google Cloud.

Risoluzione

La risoluzione del problema è diversa a seconda del sistema operativo.

SUSE

SUSE ha fornito un aggiornamento di manutenzione di Corosync che risolve il problema. Per applicare la correzione, aggiorna il software Corosync a una delle versioni elencate nella tabella seguente.

Nota: le informazioni riportate nella tabella seguente sono fornite per praticità. Per informazioni autorevoli, consulta l'articolo della knowledge base di SUSE.

Versione SUSE	Versione Corosync
SLES 12 - tutte le release 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 ha fornito un aggiornamento di manutenzione di Corosync che risolve il problema. Per applicare la correzione, aggiorna il software Corosync a una delle versioni elencate nella tabella seguente.

Nota: le informazioni riportate nella tabella seguente sono fornite per praticità. Per informazioni autorevoli, consulta l'articolo della knowledge base di Red Hat.

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

Il ripristino dei valori predefiniti di gVNIC su RHEL causa il failover nella configurazione HA

Se utilizzi il driver di rete gVNIC in combinazione con versioni di RHEL precedenti alla 8.7, potresti riscontrare un ripristino dei valori predefiniti di gVNIC che causa la perdita della connettività di rete della VM interessata per un paio di secondi, il che potrebbe comportare failover indesiderati nel cluster HA.

Potresti notare che viene generato uno stack di chiamate del kernel nel file di log dei messaggi del sistema operativo, ad esempio:

  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

Causa

La causa del problema è che le versioni di RHEL precedenti alla 8.7 contengono una compilazione precedente del driver gVNIC che non dispone dei miglioramenti e delle patch di stabilità richiesti.

Risoluzione

Utilizza una versione di RHEL certificata SAP successiva alla 8.7, in combinazione con il driver gVNIC. Questa operazione è particolarmente importante se utilizzi una macchina di Compute Engine di terza generazione, ad esempio M3, perché non supporta l'utilizzo del driver VirtIO, quindi devi utilizzare il driver gVNIC. Per l'elenco completo dei tipi di macchine che utilizzano per impostazione predefinita gVNIC, consulta la tabella Confronto delle serie di macchine.