Problèmes connus

Cette page décrit les problèmes connus que vous pourriez rencontrer lors de l'utilisation de SAP sur Google Cloud. Elle n'inclut que les problèmes signalés par les spécialistes SAP à l'équipe du Cloud Customer Care.

D'autres problèmes susceptibles d'affecter les systèmes SAP peuvent être décrits dans la documentation concernant d'autres produits et services Google Cloud. Par exemple, les problèmes liés aux VM Compute Engine, aux disques persistants ou aux images d'OS sont regroupés sur la page Problèmes connus dans Compute Engine.

Les modifications apportées à la méthode de cloisonnement par défaut peuvent entraîner l'expiration du cloisonnement dans RHEL 8.4.

Si vous utilisez RHEL 8.4 avec les versions fence-agents-gce 4.2.1-65 à 4.2.1-69 de l'agent de cloisonnement, un délai avant expiration de cloisonnement peut se produire.

Les versions fence-agents-gce 4.2.1-65 à 4.2.1-69 de l'agent de cloisonnement ne définissent pas la méthode de cloisonnement par défaut cycle. Par conséquent, la méthode de cloisonnement par défaut revient à la méthode onoff. L'agent de cloisonnement effectue alors un appel d'API stop et un appel d'API start au lieu d'un seul appel d'API reset. Le processus de cloisonnement prend donc plus de temps pour accéder aux API, ce qui peut entraîner un délai d'expiration du cloisonnement.

Solution

Pour résoudre ce problème, essayez les options suivantes :

Remplacez la méthode de cloisonnement par défaut par cycle à l'aide de la commande suivante :
```
pcs resource update <STONITH_device_name> method=cycle
```
Vérifiez votre version de fence-agents-gce et assurez-vous que vous utilisez la version 4.2.1-70 ou ultérieure :
- Pour vérifier la version de votre agent de cloisonnement, exécutez la commande suivante :
```
yum info fence-agents-gce
```
- Pour mettre à jour votre agent de cloisonnement, exécutez la commande suivante:
```
yum --releasever=8.6 update fence-agents-gce
```

StorageException pour Cloud Storage peut entraîner une sauvegarde corrompue de l'agent Backint

Dans certaines conditions, si StorageException se produit lorsque l'agent Backint de Cloud Storage pour SAP HANA stocke une sauvegarde dans Cloud Storage, l'agent Backint peut ajouter des données en double au fichier de sauvegarde, ce qui génère un fichier de sauvegarde inutilisable pour la récupération.

Si vous essayez de récupérer la base de données à partir d'un fichier de sauvegarde contenant des données en double, le message d'erreur suivant s'affiche :

  exception 3020043: Wrong checksum

Utilisateurs concernés

Utilisateurs SAP HANA qui utilisent l'agent Backint de Cloud Storage pour SAP HANA pour stocker des sauvegardes dans Cloud Storage.

Solution

Pour résoudre ce problème, commencez par installer la version 1.0.13 ou ultérieure de l'agent Backint, puis recherchez les erreurs StorageException dans les journaux de l'agent Backint pour voir si vous êtes concerné par ce problème.

Pour obtenir des instructions sur la mise à niveau de l'agent Backint, consultez la section Mettre à jour l'agent Backint vers une nouvelle version.

Pour savoir si vous êtes concerné par ce problème, consultez les journaux de l'agent Backint :

En tant qu'utilisateur sidadm sur l'hôte SAP HANA, recherchez le message StorageException dans les journaux :

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

Si vous trouvez le message d'erreur, vérifiez l'état de la sauvegarde associée :
```
$ 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>
```
Dans l'exemple, remplacez les valeurs d'espace réservé suivantes :
- EBID par l'ID de sauvegarde externe de la sauvegarde
- BACKUP_FILE_NAME par le nom du fichier de sauvegarde
Si vous recevez une erreur checksum, contactez le service Cloud Customer Care.

Outre la vérification précédente, pour détecter ce problème et d'autres problèmes avant de procéder à vos sauvegardes, intégrez régulièrement les actions suivantes dans le processus de sauvegarde :

Conformément aux bonnes pratiques recommandées par SAP, exécutez l'outil SAP hdbbackupcheck régulièrement sur des sauvegardes pour vérifier la cohérence logique. Pour en savoir plus, référez-vous à la note SAP 1869119.
Testez régulièrement vos procédures de reprise après sinistre.

Échec du déploiement SAP HANA à scaling horizontal en raison d'une erreur Python

Si vous installez SAP HANA 2.0 SPS 5 Revision 56 ou une version ultérieure pour un système SAP HANA à scaling horizontal avec basculement automatique des hôtes, le déploiement de SAP HANA à scaling horizontal avec basculement automatique des hôtes échoue en raison d'une erreur Python dans le gestionnaire d'espace de stockage pour SAP HANA. Les fichiers journaux de trace SAP HANA affichent l'erreur Python suivante pour cet échec : failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'.

Solution

Utilisez la version 2.2 ou ultérieure du gestionnaire d'espace de stockage pour SAP HANA. La version 2.2 est compatible avec SAP HANA 2.0 SPS 5 Revision 56 et versions ultérieures. Pour en savoir plus sur le gestionnaire d'espace de stockage pour SAP HANA, consultez la page Basculement automatique des hôtes SAP HANA sur Google Cloud.

Problème de basculement de cluster à haute disponibilité en raison d'un délai de communication Corosync

Pour votre cluster à haute disponibilité pour SAP HANA sur Google Cloud, le basculement peut être déclenché de manière incorrecte en raison d'un délai temporaire dans la transmission des messages Corosync entre les nœuds du cluster.

Ce problème survient sur les distributions Linux à haute disponibilité SUSE et Red Hat.

Ce problème n'est pas spécifique à Google Cloud mais il est tout de même décrit ici car il a affecté SAP pour les utilisateurs de Google Cloud.

Solution

La résolution du problème varie en fonction de votre système d'exploitation.

SUSE

SUSE a fourni une mise à jour de maintenance Corosync qui résout le problème. Pour appliquer le correctif, mettez à jour votre logiciel Corosync vers l'une des versions répertoriées dans le tableau suivant.

Version SUSE	Version Corosync
SLES 12 - toutes les versions 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 a fourni une mise à jour de maintenance Corosync qui résout le problème. Pour appliquer le correctif, mettez à jour votre logiciel Corosync vers l'une des versions répertoriées dans le tableau suivant.

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

La réinitialisation de gVNIC sur RHEL entraîne un basculement dans la configuration de la haute disponibilité

Si vous utilisez le pilote de réseau gVNIC conjointement avec des versions de RHEL antérieures à la version 8.7, vous pouvez rencontrer une réinitialisation gVNIC entraînant la perte de connectivité réseau de la VM concernée pendant quelques secondes, ce qui peut entraîner des basculements indésirables dans votre cluster à haute disponibilité.

Vous pouvez observer qu'une pile d'appels de noyau est générée dans le fichier journal des messages du système d'exploitation, par exemple:

  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

Cause

La cause de ce problème est que les versions de RHEL antérieures à 8.7 contiennent une version antérieure du pilote gVNIC qui ne dispose pas des améliorations et des correctifs de stabilité requis.

Solution

Utilisez une version de RHEL certifiée SAP ultérieure à la version 8.7, en combinaison avec le pilote gVNIC. Cette opération est particulièrement importante si vous utilisez une machine de troisième génération à partir de Compute Engine, telle que M3, car elles ne sont pas compatibles avec le pilote VirtIO. nécessitant l'utilisation du pilote gVNIC. Pour obtenir la liste complète des types de machines qui utilisent gVNIC par défaut, consultez le tableau Comparaison des séries de machines.