Problemas conocidos

En esta página, se describen problemas conocidos con los que puedes encontrarte cuando usas SAP en Google Cloud. En la página, solo se incluyen los problemas que los especialistas de SAP informaron al equipo de Atención al cliente de Cloud.

Otros problemas que pueden afectar a los sistemas SAP pueden aparecer en la documentación de otros productos y servicios de Google Cloud. Por ejemplo, los problemas relacionados con las VM de Compute Engine, los discos persistentes o las imágenes de SO se enumeran en la página de problemas conocidos de Compute Engine.

Los cambios en el método de protección predeterminado pueden causar el tiempo de espera de la protección en RHEL 8.4

Si usas RHEL 8.4 con el agente de protección fence-agents-gce, las versiones 4.2.1-65 a 4.2.1-69, es posible que se agote el tiempo de espera de la protección.

El agente de protección fence-agents-gce de las versiones 4.2.1-65 a la 4.2.1-69 no definen el método de protección predeterminado cycle. Como resultado, el método de protección predeterminado recurre al método onoff. Esto hace que el agente de protección realice una llamada a la API stop y una llamada a la API start en lugar de una sola llamada a la API reset. Por lo tanto, el proceso de protección tarda más en acceder a las API, lo que puede provocar un tiempo de espera de protección.

Solución

Para resolver este problema, puedes probar las siguientes opciones:

• Cambia el método de protección predeterminado a cycle con el siguiente comando:

  pcs resource update <STONITH_device_name> method=cycle
  

• Verifica tu versión de fence-agents-gce y asegúrate de usar la versión 4.2.1-70 o posterior.

  • Para verificar la versión del agente de protección, ejecuta el siguiente comando:

  yum info fence-agents-gce
  

  • Para actualizar la protección, ejecuta el siguiente comando:

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

StorageException para Cloud Storage puede causar que se dañen las copias de seguridad del agente de Backint

CORREGIDO: Se corrigió este problema. Para obtener información sobre cómo aplicar la corrección y ver si te ves afectado, consulta Resolución en esta página.

En ciertas condiciones, si se produce una StorageException cuando el agente de Backint de Cloud Storage para SAP HANA almacena una copia de seguridad en Cloud Storage, el agente de Backint puede agregar datos duplicados al archivo de copia de seguridad, lo que hace que este último no se pueda usar para la recuperación.

Si intentas recuperar la base de datos de un archivo de copia de seguridad con datos duplicados, recibirás el siguiente error:

  exception 3020043: Wrong checksum

Usuarios afectados

Usuarios de SAP HANA que usan el agente de Backint de Cloud Storage para SAP HANA a fin de almacenar copias de seguridad en Cloud Storage

Solución

Para resolver este problema, primero instala la versión 1.0.13 o posterior del agente de Backint y, luego, revisa sus registros en busca de errores de StorageException para ver si te afectó este problema.

Si deseas obtener instrucciones para actualizar el agente de Backint, consulta Actualiza el agente de Backint a una versión nueva.

Para ver si este problema te afectó, consulta los registros del agente de Backint:

1. Como usuario sidadm en el host de SAP HANA, busca los registros en el mensaje StorageException:

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

2. Si encuentras el mensaje de error, verifica el estado de la copia de seguridad asociada:

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

   En el ejemplo, reemplaza los siguientes valores de marcador de posición:

   • EBID por el ID de la copia de seguridad externa
   • BACKUP_FILE_NAME por el nombre del archivo de copia de seguridad

   Si recibes un error checksum, comunícate con el servicio de Atención al cliente de Cloud.

Además de la verificación anterior, para detectar este y otros problemas antes de que se necesiten tus copias de seguridad, haz que las siguientes acciones sean parte regular de tu proceso de copia de seguridad:

• Según las prácticas recomendadas de SAP, ejecuta la herramienta hdbbackupcheck de SAP de forma periódica en las copias de seguridad para verificar la coherencia lógica. Para obtener más información, consulta SAP Note 1869119.
• Prueba los procedimientos de recuperación ante desastres con regularidad.

La implementación del escalamiento horizontal de SAP HANA falla debido a un error de Python

Si instalas SAP HANA 2.0 SPS 5 Revisión 56 o posterior para un sistema SAP HANA de escalamiento horizontal con conmutación por error automática de host, la implementación de la escala horizontal de SAP HANA con conmutación por error automática de host falla debido a un error de Python en el administrador de almacenamiento de SAP HANA. En los archivos de registro de seguimiento de SAP HANA, se muestra el siguiente error de Python para esta falla: failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'.

Solución

Usa la versión 2.2 o posterior del administrador de almacenamiento para SAP HANA. La versión 2.2 agrega compatibilidad con la de SAP HANA 2.0 SPS 5 Revisión 56 y versiones posteriores. Si deseas obtener más información sobre el administrador de almacenamiento para SAP HANA, consulta Conmutación por error automática del host de SAP HANA en Google Cloud.

Problema de conmutación por error del clúster de alta disponibilidad debido a un retraso en la comunicación de Corosync

En el caso de tu clúster con alta disponibilidad (HA) para SAP HANA en Google Cloud, la conmutación por error se puede activar de manera incorrecta debido a un retraso temporal en la transmisión de mensajes de Corosync entre los nodos del clúster.

Este problema se produce en distribuciones de Linux de alta disponibilidad de SUSE y Red Hat.

Este problema no es específico de Google Cloud, pero se describe aquí porque ha afectado a SAP en los usuarios de Google Cloud.

Solución

La resolución del problema es diferente según tu sistema operativo.

SUSE

SUSE proporcionó una actualización de mantenimiento de Corosync que resuelve el problema. Para aplicar la corrección, actualiza tu software de Corosync a una de las versiones que se enumeran en la tabla siguiente.

Nota: La información de la siguiente tabla se proporciona para tu conveniencia. Para obtener la información autorizada, consulta el artículo de la base de conocimiento de SUSE.

Versión de SUSE	Versión de Corosync
SLES 12: todas las versiones de 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 proporcionó una actualización de mantenimiento de Corosync que resuelve el problema. Para aplicar la corrección, actualiza tu software de Corosync a una de las versiones que se enumeran en la tabla siguiente.

Nota: La información de la siguiente tabla se proporciona para tu conveniencia. Para obtener la información autorizada, consulta el artículo de la base de conocimiento de Red Hat.

Versión de Red Hat	Versión de Corosync
RHEL 7	corosync-2.4.5-7.el7_9.2
RHEL 8	corosync-3.1.5-2.el8

El restablecimiento de gVNIC en RHEL genera una conmutación por error en la configuración de alta disponibilidad

Si usas el controlador de red gVNIC en combinación con versiones de RHEL anteriores a la 8.7, es posible que experimentes un restablecimiento de gVNIC que haga que la VM en cuestión pierda conectividad de red durante un par de segundos, lo que podría provocar conmutaciones por error no deseadas en tu clúster de HA.

Es posible que observes una pila de llamadas de kernel que se genera en el archivo de registro de mensajes del SO, por ejemplo:

  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 de este problema es que las versiones de RHEL anteriores a la 8.7 contienen una compilación anterior del controlador de gVNIC que no tiene las mejoras y los parches de estabilidad necesarios.

Solución

Usa una versión de RHEL con certificación de SAP que sea posterior a 8.7, en combinación con el controlador de gVNIC. Esto es muy importante si usas una máquina de tercera generación de Compute Engine, como M3, porque no admiten el uso del controlador VirtIO, por lo tanto que requiere que uses el controlador de gVNIC. Para obtener la lista completa de los tipos de máquinas que se establecen de forma predeterminada en gVNIC, consulta la tabla Comparación de series de máquinas.