이 페이지에서는 Google Cloud 기반 SAP를 사용하는 동안 발생할 수 있는 알려진 문제를 설명합니다. 이 페이지에는 Cloud Customer Care 팀의 SAP 전문가가 발견한 문제만 포함되어 있습니다.
SAP 시스템에 영향을 줄 수 있는 다른 문제는 다른 Google Cloud 제품 및 서비스 문서에 나열되어 있을 수 있습니다. 예를 들어 Compute Engine VM, 영구 디스크 또는 OS 이미지와 관련된 문제는 Compute Engine 알려진 문제 페이지에 나열되어 있습니다.
기본 펜싱 메서드를 변경하면 RHEL 8.4에서 펜싱 제한 시간이 발생할 수 있음
펜스 에이전트 fence-agents-gce 버전 4.2.1-65 ~ 4.2.1-69에서 RHEL 8.4를 사용하는 경우 펜싱 제한 시간이 발생할 수 있습니다.
펜스 에이전트 fence-agents-gce 버전 4.2.1-65 ~ 4.2.1-69는 기본 펜싱 메서드 cycle을 정의하지 않습니다. 따라서 기본 펜싱 메서드는 onoff 메서드로 대체됩니다. 이렇게 하면 펜싱 에이전트가 단일 reset API 호출 대신 stop API 호출 및 start API 호출을 수행합니다.
따라서 펜싱 프로세스가 API에 액세스하는 데 시간이 더 걸리므로 펜싱 제한 시간이 발생할 수 있습니다.
해결 방법
이 문제를 해결하려면 다음 옵션을 시도해 보세요.
다음 명령어를 사용하여 기본 펜싱 메서드를
cycle로 변경합니다.pcs resource update <STONITH_device_name> method=cyclefence-agents-gce버전을 확인하고4.2.1-70버전 이상을 사용 중인지 확인합니다.- 펜스 에이전트 버전을 확인하려면 다음 명령어를 실행합니다.
yum info fence-agents-gce- 펜스 에이전트를 업데이트하려면 다음 명령어를 실행합니다.
yum --releasever=8.6 update fence-agents-gce
Cloud Storage의 StorageException으로 인해 Backint 에이전트 백업이 손상될 수 있음
특정 조건에서 SAP HANA용 Cloud Storage Backint 에이전트가 Cloud Storage에 백업을 저장할 때 StorageException이 발생하면 Backint 에이전트는 백업 파일에 중복 데이터를 추가할 수 있고 이로 인해 복구에 백업 파일을 사용할 수 없습니다.
중복 데이터가 있는 백업 파일에서 데이터베이스를 복구하려고 하면 다음 오류가 발생합니다.
exception 3020043: Wrong checksum
사용자에게 영향이 있음
SAP HANA용 Cloud Storage Backint 에이전트를 사용하여 Cloud Storage에 백업을 저장하는 SAP HANA 사용자입니다.
해결 방법
이 문제를 해결하려면 먼저 Backint 에이전트 버전 1.0.13 이상을 설치한 후 Backint 에이전트 로그에서 StorageException 오류가 있는지 확인하여 이 문제의 영향을 받는지 확인합니다.
Backint 에이전트를 업그레이드하는 방법은 Backint 에이전트를 새 버전으로 업데이트를 참조하세요.
이 문제의 영향을 받았는지 확인하려면 Backint 에이전트 로그를 확인합니다.
SAP HANA 호스트에서 sidadm 사용자로
StorageException메시지의 로그를 검색합니다.grep 'com.google.cloud.storage.StorageException' \ /usr/sap/$SAPSYSTEMNAME/SYS/global/hdb/opt/backint/backint-gcs/logs/*.log.*오류 메시지가 표시되면 연결된 백업의 상태를 확인합니다.
$ 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>이 예시에서는 다음 자리표시자 값을 바꿉니다.
- EBID를 백업의 외부 백업 ID로 바꿉니다.
- BACKUP_FILE_NAME을 백업 파일의 파일 이름으로 바꿉니다.
checksum오류가 발생하면 Cloud Customer Care에 문의하세요.
위의 확인 외에도 백업이 필요하기 전에 이 문제 및 기타 문제를 감지하려면 다음 작업을 백업 프로세스의 일반적인 절차로 만드세요.
- SAP 권장사항에 따라 백업에 대해 SAP
hdbbackupcheck도구를 정기적으로 실행하여 논리적 일관성을 확인합니다. 자세한 내용은 SAP Note 1869119를 참조하세요. - 재해 복구 절차를 정기적으로 테스트합니다.
Python 오류로 인한 SAP HANA 수평 확장 배포 실패
호스트 자동 장애 조치가 포함된 SAP HANA 수평 확장 시스템에 SAP HANA 2.0 SPS 5 버전 56 이상을 설치하는 경우 SAP HANA 스토리지 관리자의 Python 오류로 인해 호스트 자동 장애 조치 배포가 포함된 SAP HANA 수평 확장이 실패합니다.
SAP HANA trace 로그 파일에 이 실패에 대한 다음 Python 오류가 표시됩니다. failed with python error: _sap_hana_forbid() got an unexpected keyword argument 'stdout'
해결 방법
SAP HANA용 스토리지 관리자 버전 2.2 이상을 사용합니다. 버전 2.2는 SAP HANA 2.0 SPS 5 버전 56 이상을 지원합니다. SAP HANA용 스토리지 관리자에 대한 자세한 내용은 Google Cloud에서 SAP HANA 호스트 자동 장애 조치를 참조하세요.
Corosync 통신 지연으로 인한 고가용성 클러스터 장애 조치 문제
Google Cloud 기반 SAP HANA용 고가용성(HA) 클러스터의 경우 클러스터 노드 간 Corosync 메시지 전송의 일시적 지연으로 인해 장애 조치가 잘못 트리거될 수 있습니다.
이 문제는 SUSE 및 Red Hat 고가용성 Linux 배포판 모두에서 발생합니다.
이 문제는 Google Cloud에 국한되지 않지만 Google Cloud 기반 SAP 사용자에 영향을 미쳤기 때문에 여기에서 설명합니다.
해결 방법
문제 해결 방법은 운영체제에 따라 다릅니다.
SUSE
SUSE에서 문제를 해결하는 Corosync 유지보수 업데이트를 제공했습니다. 수정사항을 적용하려면 Corosync 소프트웨어를 다음 표에 나열된 버전 중 하나로 업데이트합니다.
| SUSE 버전 | Corosync 버전 |
|---|---|
| SLES 12 - 모든 서비스 팩(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에서 이 문제를 해결하는 Corosync 유지보수 업데이트를 제공했습니다. 수정사항을 적용하려면 Corosync 소프트웨어를 다음 표에 나열된 버전 중 하나로 업데이트합니다.
| Red Hat 버전 | Corosync 버전 |
|---|---|
| RHEL 7 | corosync-2.4.5-7.el7_9.2 |
| RHEL 8 | corosync-3.1.5-2.el8 |
RHEL에서 gVNIC를 재설정하여 HA 구성에 장애 조치 발생
gVNIC 네트워크 드라이버를 8.7 이전 버전의 RHEL과 함께 사용하면 gVNIC 재설정이 발생하여 해당 VM에서 몇 초 동안 네트워크 연결이 끊어지고, 이로 인해 HA 클러스터에서 원치 않는 장애 조치가 발생할 수 있습니다.
OS의 메시지 로그 파일에서 커널 호출 스택이 생성될 수 있습니다. 예를 들면 다음과 같습니다.
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
원인
이 문제의 원인은 8.7 이전의 RHEL 버전에 포함된 gVNIC 드라이버의 이전 빌드에, 필요한 개선사항 및 안정성 패치가 적용되지 않았기 때문입니다.
해결 방법
8.7 이상의 RHEL SAP 인증 버전을 gVNIC 드라이버와 함께 사용합니다. 특히, M3과 같은 Compute Engine의 3세대 머신을 사용하는 경우 VirtIO 드라이버 사용을 지원하지 않으므로 반드시 gVNIC 드라이버를 사용해야 합니다. gVNIC로 기본 설정된 머신 유형의 전체 목록은 머신 시리즈 비교 표를 참조하세요.