In questa pagina vengono descritti i problemi noti che potresti riscontrare durante l'utilizzo SAP su Google Cloud. La pagina include solo i problemi riscontrati l'attenzione degli specialisti SAP del team dell'assistenza clienti Google Cloud.
Altri problemi che possono influire sui sistemi SAP potrebbero essere elencati nella documentazione per e altri prodotti e servizi Google Cloud. Ad esempio, problemi che sono correlate alle VM di Compute Engine, o immagini sistema operativo, sono elencati nella Pagina dei problemi noti di Compute Engine.
Le modifiche al metodo di scherma predefinito possono causare un timeout di scherma in RHEL 8.4
Se utilizzi RHEL 8.4 con le versioni fence-agents-gce
dell'agente di fence
4.2.1-65
a 4.2.1-69
, potrebbe verificarsi un timeout della scherma.
Le versioni da 4.2.1-65
a 4.2.1-69
dell'agente fence fence-agents-gce
non devono
definiscono il metodo di scherma predefinito cycle
. Di conseguenza, la recinzione predefinita
torna al metodo onoff
. Questo fa sì che l'agente di recinzione prenda
una chiamata API stop
e una chiamata API start
anziché una singola chiamata API reset
.
Pertanto, il processo di scherma richiede più tempo per accedere alle API, il che può
un timeout per la scherma.
Risoluzione
Per risolvere il problema, prova le seguenti opzioni:
Cambia il metodo di scherma 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 lo versione4.2.1-70
o successiva:- Per verificare la versione dell'agente di fence, esegui questo comando:
yum info fence-agents-gce
- Per aggiornare l'agente di recinto, esegui questo comando:
yum --releasever=8.6 update fence-agents-gce
StorageException per Cloud Storage può causare il backup danneggiato dell'agente Backint
In determinate condizioni, se si verifica un'eccezione StorageException quando l'agente Backint di Cloud Storage per SAP HANA un backup in Cloud Storage, l'agente Backint potrebbe aggiungere dati duplicati al file di backup. In questo modo, il file di backup non utilizzabili per il ripristino.
Se tenti di recuperare il database da un file di backup con file di dati, viene visualizzato il seguente errore:
exception 3020043: Wrong checksum
Utenti interessati
Utenti SAP HANA che utilizzano l'agente Backint Cloud Storage per SAP HANA per archiviare i backup in Cloud Storage.
Risoluzione
Per risolvere il problema, installare prima la versione 1.0.13 o successiva del dell'agente Backint, quindi controlla i log dell'agente Backint. per eventuali errori StorageException per vedere se questa modifica ti riguarda problema.
Per istruzioni sull'upgrade dell'agente Backint, consulta Aggiornamento dell'agente Backint a una nuova versione
Per verificare se questo problema ti riguarda, controlla se Log dell'agente Backint:
In qualità di sidutente adm nell'host SAP HANA, cerca nei log il messaggio
StorageException
:grep 'com.google.cloud.storage.StorageException' \ /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/opt/backint/backint-gcs/logs/*.log.*
Se vedi 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 viene visualizzato 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, rendi regolarmente le seguenti azioni il processo di backup:
- In base alle best practice consigliate per SAP, esegui il SAP
hdbbackupcheck
regolarmente sui backup per verificare la coerenza logica. Per ulteriori informazioni informazioni, consulta la nota SAP 1869119. - Testa regolarmente le tue procedure di ripristino di emergenza.
Il deployment dello scale out di SAP HANA non riesce a causa di un errore Python
Se stai installando SAP HANA 2.0 SPS 5 Revisione 56 o successiva per un SAP HANA
sistema di scale out con failover automatico dell'host, lo scale out di SAP HANA con host
il deployment del failover automatico non riesce a causa di un errore Python in Gestione archiviazione per SAP HANA.
I file di log di traccia 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 revisione 56 e successive. Per ulteriori informazioni sui Gestione archiviazione per SAP HANA, consulta l'articolo relativo al failover automatico dell'host SAP HANA su Google Cloud.
Problema di failover del cluster ad alta disponibilità dovuto a un ritardo nella comunicazione Corosync
Per il tuo cluster ad alta disponibilità (HA) per SAP HANA su Google Cloud, può essere attivato in modo errato a causa di un ritardo temporaneo nella trasmissione di Corosync tra i nodi del cluster.
Questo problema si verifica nelle distribuzioni Linux ad alta disponibilità sia SUSE sia Red Hat.
Questo problema non è specifico di Google Cloud, ma è descritto qui perché ha avuto un impatto su SAP sugli utenti di Google Cloud.
Risoluzione
La risoluzione del problema varia a seconda del sistema operativo.
SUSE
SUSE ha fornito un aggiornamento di manutenzione di Corosync che ha risolto il problema. Per applicare la correzione, aggiorna il software Corosync a una delle versioni elencate in la tabella seguente.
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 ha risolto il problema. Per applicare la correzione, aggiorna il software Corosync a una delle versioni elencate in la tabella seguente.
Versione Red Hat | Versione Corosync |
---|---|
RHEL 7 | corosync-2.4.5-7.el7_9.2 |
RHEL 8 | corosync-3.1.5-2.el8 |
La reimpostazione di gVNIC su RHEL causa il failover nella configurazione ad alta disponibilità
Se utilizzi il driver di rete gVNIC insieme alle versioni di RHEL prima della versione 8.7, si potrebbe verificare un ripristino di gVNIC che causa la perdere la connettività di rete per un paio di secondi, di failover indesiderati nel cluster ad alta disponibilità.
Potresti osservare che viene generato uno stack di chiamate al 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 di questo problema è che le versioni RHEL precedenti alla 8.7 contengono una versione build del driver gVNIC che non presenta i miglioramenti richiesti e patch di stabilità.
Risoluzione
Usa una versione di RHEL certificata per SAP successiva alla 8.7, in combinazione con il driver gVNIC. Questa operazione è particolarmente importante se utilizzi una terza di machine learning da Compute Engine, M3, perché non di supporto utilizzando il driver VirtIO, richiedendo l'uso del driver gVNIC. Per l'elenco completo dei tipi di macchina predefiniti per gVNIC, consulta Serie di macchine confronto.