Problemas conhecidos

Nesta página, descrevemos problemas conhecidos que você pode encontrar ao usar a SAP no Google Cloud. A página inclui apenas os problemas que foram informados aos especialistas da SAP na equipe de Cloud Customer Care.

Outros problemas que podem afetar os sistemas SAP podem estar listados na documentação de outros produtos e serviços do Google Cloud. Por exemplo, os problemas relacionados a VMs do Compute Engine, discos permanentes ou imagens do SO estão listados na página Problemas conhecidos do Compute Engine.

Alterações no método de isolamento padrão podem causar o tempo limite de isolamento no RHEL 8.4

Se você estiver usando o RHEL 8.4 com o agente de limite fence-agents-gce versões 4.2.1-65 a 4.2.1-69, poderá ocorrer um tempo limite de isolamento.

O agente de isolamento fence-agents-gce versões 4.2.1-65 a 4.2.1-69 não define o método de isolamento padrão cycle. Como resultado, o método de isolamento padrão volta a usar o método onoff. Isso faz com que o agente de isolamento faça uma chamada de API stop e uma chamada de API start em vez de uma única chamada de API reset. Portanto, o processo de isolamento leva mais tempo para acessar as APIs, o que pode levar a um tempo limite de isolamento.

Resolução

Para resolver esse problema, tente as seguintes opções:

• Mude o método de isolamento padrão para cycle usando o seguinte comando:

  pcs resource update <STONITH_device_name> method=cycle
  

• Verifique a versão do fence-agents-gce e se você está usando a 4.2.1-70 ou posterior:

  • Para verificar a versão do agente de isolamento, execute o seguinte comando:

  yum info fence-agents-gce
  

  • Para atualizar seu agente de limite, execute o seguinte comando:

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

StorageException para Cloud Storage pode causar um backup corrompido do agente Backint

CORRIGIDO: esse problema foi resolvido. Para informações sobre como aplicar a correção e ver se você foi afetado, consulte Resolução nesta página.

Em determinadas condições, se uma StorageException ocorrer quando o agente Backint do Cloud Storage para SAP HANA armazenar um backup no Cloud Storage, o agente Backint poderá anexar dados duplicados ao arquivo de backup, o que torna o arquivo de backup inutilizável para recuperação.

Se você tentar recuperar o banco de dados a partir de um arquivo de backup com dados duplicados, receberá o seguinte erro:

  exception 3020043: Wrong checksum

Usuários afetados

Usuários do SAP HANA que usam o agente Backint do Cloud Storage para SAP HANA para armazenar backups no Cloud Storage.

Resolução

Para resolver esse problema, primeiro instale a versão 1.0.13 ou posterior do agente do Backint e, em seguida, verifique se há erros do tipo StorageException nos registros do agente do Backint para ver se você foi afetado por esse problema.

Para instruções sobre como atualizar o agente do Backint, consulte Como atualizar o agente do Backint para uma nova versão

Para ver se você foi afetado por esse problema, verifique os registros do agente do Backint:

1. Como usuário sidadm no host do SAP HANA, pesquise os registros da mensagem StorageException:

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

2. Se você encontrar a mensagem de erro, verifique o status do backup associado:

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

   No exemplo, substitua os seguintes valores de marcador:

   • EBID pelo ID de backup externo do backup;
   • BACKUP_FILE_NAME pelo nome do arquivo de backup;

   Se você receber um erro checksum, entre em contato com o atendimento ao cliente do Cloud.

Além da verificação anterior, para detectar esse e outros problemas antes da necessidade dos backups, faça das seguintes ações uma parte regular do processo de backup:

• De acordo com as práticas recomendadas da SAP, execute a ferramenta hdbbackupcheck da SAP regularmente em backups para verificar a consistência lógica. Para mais informações, consulte a Nota SAP 1869119.
• Teste regularmente os procedimentos de recuperação de desastres.

A implantação de escalonamento horizontal do SAP HANA falha devido a um erro do Python

Se você estiver instalando o SAP HANA 2.0 SPS 5 Revisão 56 ou mais recente para um sistema de escalonamento horizontal do SAP HANA com failover automático do host, o escalonamento horizontal do SAP HANA com implantação de failover automático do host falhará devido a um erro do Python no gerenciador de armazenamento do SAP HANA. Os arquivos de registros de rastreamento do SAP HANA mostram o seguinte erro do Python para essa falha: failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'.

Resolução

Use a versão 2.2 ou posterior do gerenciador de armazenamento do SAP HANA. A versão 2.2 adiciona compatibilidade com o SAP HANA 2.0 SPS 5 Revisão 56 e posterior. Para mais informações sobre o gerenciador de armazenamento do SAP HANA, consulte Failover automático do host do SAP HANA no Google Cloud.

Problema de failover de cluster de alta disponibilidade devido a um atraso na comunicação do Corosync

Para o cluster de alta disponibilidade (HA, na sigla em inglês) de SAP HANA no Google Cloud, o failover pode ser acionado incorretamente devido a um atraso temporário na transmissão de mensagens do Corosync entre os nós do cluster.

Esse problema ocorre nas distribuições Linux de alta disponibilidade e SUSE do Red Hat.

Esse problema não é específico do Google Cloud, mas é descrito aqui porque afetou o SAP nos usuários do Google Cloud.

Resolução

A resolução do problema varia de acordo com seu sistema operacional.

SUSE

O SUSE forneceu uma atualização de manutenção do Corosync que resolve o problema. Para aplicar a correção, atualize o software do Corosync para uma das versões listadas na tabela a seguir.

Observação: as informações na tabela a seguir são fornecidas por conveniência. Veja as informações confiáveis no artigo da base de conhecimento do SUSE (em inglês).

Versão do SUSE	Versão do Corosync
SLES 12: todas as versões do 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

A Red Hat forneceu uma atualização de manutenção do Corosync que resolve o problema. Para aplicar a correção, atualize o software do Corosync para uma das versões listadas na tabela a seguir.

Observação: as informações na tabela a seguir são fornecidas por conveniência. Para informações confiáveis, consulte o artigo da base de conhecimento do Red Hat.

Versão do Red Hat	Versão do Corosync
RHEL 7	corosync-2.4.5-7.el7_9.2
RHEL 8	corosync-3.1.5-2.el8

A redefinição da gVNIC no RHEL causa failover na configuração de alta disponibilidade

Se você estiver usando o driver de rede gVNIC em combinação com versões do RHEL anteriores à 8.7, poderá enfrentar uma redefinição da gVNIC fazendo com que a VM em questão perca a conectividade de rede por alguns segundos, o que pode resultar em failovers indesejados no cluster de alta disponibilidade.

Você pode observar uma pilha de chamadas do kernel sendo gerada no arquivo de registro de mensagens do SO, por exemplo:

  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

A causa desse problema é que as versões do RHEL anteriores à 8.7 contêm um build anterior do driver gVNIC que não tem as melhorias e os patches de estabilidade necessários.

Resolução

Use uma versão do RHEL certificada pela SAP que seja posterior à 8.7, além do driver da gVNIC. Isso é especialmente importante se você estiver usando uma máquina de terceira geração do Compute Engine, como M3, porque ela não é compatível com o uso do driver VirtIO. Assim, que exige o uso do driver da gVNIC. Para ver a lista completa de tipos de máquina que usam gVNIC como padrão, consulte a tabela Comparação de séries de máquinas.