Skip to main content
NetApp Solutions SAP
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

SnapCenter으로 SAP HANA 시스템 업데이트

기여자
PDF

다음 섹션에서는 SAP HANA 데이터베이스의 다양한 시스템 업데이트 작업 옵션에 대한 단계별 설명을 제공합니다.

SAP HANA 데이터베이스 구성에 따라 추가 단계가 실행되거나 준비되어야 합니다. 아래 표에 요약이 나와 있습니다.

소스 시스템 소스 시스템 구성 SnapCenter 및 SAP HANA 운영

MDC 단일 테넌트 + SID = 테넌트 이름입니다

표준 구성

SnapCenter 클론 작업 및 선택적 복구 스크립트 실행

SAP HANA 지속성 암호화

처음에 또는 소스 시스템에서 루트 키가 변경된 경우 복구를 실행하기 전에 대상 시스템에서 루트 키 백업을 가져와야 합니다.

SAP HANA 시스템 복제 소스

추가 단계가 필요하지 않습니다. 대상 시스템에 구성된 HSR이 없는 경우 독립 실행형 시스템으로 유지됩니다.

SAP HANA 다중 파티션

추가 단계가 필요하지 않지만 대상 시스템에서 SAP HANA 볼륨 파티션의 마운트 지점을 동일한 명명 규칙을 사용하여 사용할 수 있어야 합니다(SID만 다름).

MDC 다중 테넌트

또는 SID가 <> 테넌트 이름인 MDC Single Tenant+를 입력합니다

표준 구성

SnapCenter 클론 작업 및 선택적 복구 스크립트 실행 스크립트는 모든 테넌트를 복구합니다. 타겟 시스템 이름에 테넌트 또는 테넌트 이름이 없으면 SAP HANA 복구 작업 중에 필요한 디렉토리가 자동으로 생성됩니다. 테넌트 이름은 소스와 같으며 필요한 경우 복구 후 이름을 변경해야 합니다.

SAP HANA 지속성 암호화

소스 시스템의 DBID가 이전에 타겟 시스템에 없으면 이 테넌트의 루트 키 백업을 가져오기 전에 먼저 시스템 데이터베이스를 복구해야 합니다.

HANA 시스템 복제 소스

추가 단계가 필요하지 않습니다. 대상 시스템에 구성된 HSR이 없는 경우 독립 실행형 시스템으로 유지됩니다.

HANA 다중 파티션

추가 단계가 필요하지 않지만 대상 시스템에서 SAP HANA 볼륨 파티션의 마운트 지점을 동일한 명명 규칙을 사용하여 사용할 수 있어야 합니다(SID만 다름).

이 섹션에서 다루는 시나리오는 다음과 같습니다.

  • 클론 분할 작업 없이 SAP HANA 시스템 업데이트

  • 테넌트 이름이 SID와 동일한 운영 스토리지에서 클론 생성

  • 오프 사이트 백업 스토리지에서 복제

  • 여러 테넌트를 사용하여 운영 스토리지에서 클론 복제

  • 클론 삭제 작업

  • 클론 분할 작업을 통해 SAP HANA 시스템 업데이트

  • 테넌트 이름이 SID와 동일한 운영 스토리지에서 클론 생성

  • 클론 분할 작업

사전 요구 사항 및 제한 사항

다음 섹션에서 설명하는 워크플로에는 SAP HANA 시스템 아키텍처 및 SnapCenter 구성과 관련된 몇 가지 사전 요구 사항과 제한 사항이 있습니다.

  • 설명된 워크플로는 SnapCenter 5.0 이상 버전에서만 유효합니다.

  • 설명된 워크플로우는 단일 또는 여러 테넌트가 있는 단일 호스트 SAP HANA MDC 시스템에 유효합니다. SAP HANA 다중 호스트 시스템은 포함되지 않습니다.

  • SnapCenter 자동 검색 및 자동화 스크립트 실행을 사용하려면 타겟 호스트에 SnapCenter SAP HANA 플러그인을 구축해야 합니다.

  • 워크플로는 물리적 호스트에서 NFS 또는 FCP를 사용하는 SAP HANA 시스템 또는 게스트 내 NFS 마운트를 사용하는 가상 호스트에 대해 유효합니다.

랩 설정

아래 그림은 다양한 시스템 새로 고침 작업 옵션에 사용된 랩 설정을 보여줍니다.

  • 운영 스토리지 또는 오프사이트 백업 스토리지에서 클론 생성. 테넌트 이름은 SID와 같습니다.

    • 소스 SAP HANA 시스템: 테넌트 SS1을 사용하는 SS1

    • 타겟 SAP HANA 시스템: 테넌트 QS1을 사용하는 QS1

  • 운영 스토리지에서 클론 복제, 여러 테넌트:

    • 소스 SAP HANA 시스템: Tenant1 및 Tenant2가 포함된 SM1

    • 타겟 SAP HANA 시스템: 테넌트 1과 테넌트 2가 포함된 QS1

다음 소프트웨어 버전이 사용되었습니다.

  • SnapCenter 5.0 을 참조하십시오

  • SAP HANA 시스템: HANA 2.0 SPS7 개정판 73

  • SLES 15 를 참조하십시오

  • ONTAP 9.14P1 를 참조하십시오

모든 SAP HANA 시스템은 구성 가이드에 따라 구성해야 "NFS를 포함한 NetApp AFF 시스템 기반 SAP HANA"합니다. SnapCenter 및 SAP HANA 리소스는 모범 사례 가이드를 기반으로 "SnapCenter를 사용한 SAP HANA 백업 및 복구"구성되었습니다.

초기 1회 준비 단계

초기 단계로서 대상 SAP HANA 시스템은 SnapCenter 내에서 구성해야 합니다.

  1. SAP HANA 대상 시스템 설치

  2. 에 설명된 대로 SnapCenter에서 SAP HANA 시스템 구성 "TR-4614: SnapCenter를 통한 SAP HANA 백업 및 복구"

    1. SnapCenter 백업 작업을 위한 SAP HANA 데이터베이스 사용자 구성 이 사용자는 소스 시스템과 타겟 시스템에서 동일해야 합니다.

    2. 위의 백업 사용자를 가진 <sid> adm에 대한 hdbuserstore 키의 구성. 복구에 자동화 스크립트를 사용하는 경우 키 이름은 <SID> 키여야 합니다

    3. 타겟 호스트에 SnapCenter SAP HANA 플러그인 구축 SAP HANA 시스템은 SnapCenter에 의해 자동으로 검색됩니다.

    4. SAP HANA 리소스 보호 구성(선택 사항)

초기 설치 후 첫 번째 SAP 시스템 새로 고침 작업은 다음 단계를 통해 준비됩니다.

  1. 대상 SAP HANA 시스템을 종료합니다

  2. SAP HANA 데이터 볼륨을 마운트 해제합니다.

대상 시스템에서 실행해야 하는 스크립트를 SnapCenter allowed commands config 파일에 추가해야 합니다.

hana-7:/opt/NetApp/snapcenter/scc/etc # cat /opt/NetApp/snapcenter/scc/etc/allowed_commands.config
command: mount
command: umount
command: /mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh
hana-7:/opt/NetApp/snapcenter/scc/etc #

테넌트 이름이 SID와 같은 운영 스토리지에서 클론 생성

이 섹션에서는 소스 및 타겟 시스템의 테넌트 이름이 SID와 동일한 SAP HANA 시스템 새로 고침 워크플로우에 대해 설명합니다. 스토리지 클론 복제는 기본 스토리지에서 실행되며 스크립트로 복구가 자동화됩니다. sc-system-refresh.sh

워크플로는 다음 단계로 구성됩니다.

  1. 소스 시스템에서 SAP HANA 지속성 암호화를 사용하는 경우 암호화 루트 키를 한 번 가져와야 합니다. 소스 시스템에서 키가 변경된 경우에도 가져오기가 필요합니다. 장을 참조하십시오 ""스토리지 스냅샷 백업을 사용한 SAP HANA 시스템 업데이트 작업에 대한 고려사항""

  2. 타겟 SAP HANA 시스템이 SnapCenter에서 보호되어 있는 경우 먼저 보호를 제거해야 합니다.

  3. SnapCenter 클론 생성 워크플로우

    1. 소스 SAP HANA 시스템 SS1에서 Snapshot 백업을 선택합니다.

    2. 타겟 호스트를 선택하고 타겟 호스트의 스토리지 네트워크 인터페이스를 제공합니다.

    3. 예제 QS1에서 대상 시스템의 SID를 제공합니다

    4. 필요에 따라 사후 클론 작업으로 복구용 스크립트를 제공합니다.

  4. SnapCenter 클론 생성 작업

    1. 소스 SAP HANA 시스템에서 선택한 스냅샷 백업을 기반으로 FlexClone 볼륨을 생성합니다.

    2. FlexClone 볼륨을 대상 호스트 스토리지 네트워크 인터페이스 또는 igroup으로 내보냅니다.

    3. 타겟 호스트에서 마운트 FlexClone 볼륨의 마운트 작업을 실행합니다.

    4. 이전에 구성한 경우 클론 후 작업 복구 스크립트를 실행합니다. 그렇지 않으면 SnapCenter 워크플로우가 완료될 때 복구를 수동으로 수행해야 합니다.

      • 시스템 데이터베이스 복구

      • 테넌트 이름이 QS1인 테넌트 데이터베이스 복구

  5. 필요한 경우 SnapCenter에서 타겟 SAP HANA 리소스를 보호합니다.

다음 스크린샷은 필요한 단계를 보여 줍니다.

  1. 소스 시스템 SS1에서 스냅샷 백업을 선택하고 클론 을 클릭합니다.

  1. 대상 시스템 QS1이 설치된 호스트를 선택합니다. 목표 SID로 QS1을 입력합니다. NFS 내보내기 IP 주소는 타겟 호스트의 스토리지 네트워크 인터페이스여야 합니다.

    참고 입력된 대상 SID는 SnapCenter에서 클론된 리소스를 관리하는 방법을 제어합니다. 타겟 SID가 있는 리소스가 이미 SnapCenter에 구성되어 있고 플러그인 호스트와 일치하는 경우 SnapCenter는 이 리소스에 클론을 할당합니다. SID가 타겟 호스트에 구성되어 있지 않으면 SnapCenter에서 새 리소스를 생성합니다.
    참고 클론 생성 워크플로우를 시작하기 전에 타겟 시스템 리소스와 호스트가 SnapCenter에 구성되어 있어야 합니다. 그렇지 않으면 SnapCenter에서 생성한 새 리소스는 자동 검색을 지원하지 않으며 설명된 워크플로가 작동하지 않습니다.

Fibre Channel SAN 설정에서는 내보내기 IP 주소가 필요하지 않지만 다음 화면에서 사용된 프로토콜을 제공해야 합니다.

참고 스크린샷은 FiberChannel 연결을 사용하는 다른 랩 설정을 보여 줍니다.

Azure NetApp Files와 수동 QoS 용량 풀을 사용하면 새 볼륨의 최대 처리량을 제공해야 합니다. 용량 풀에 충분한 여유 공간이 있는지 확인하십시오. 그렇지 않으면 클론 복제 워크플로우가 실패합니다.

참고 스크린샷은 Azure NetApp Files를 사용하여 Microsoft Azure에서 실행되는 다른 랩 설정을 보여 줍니다.

  1. 필요한 명령줄 옵션과 함께 선택적 클론 후 스크립트를 입력합니다. 이 예에서는 사후 클론 스크립트를 사용하여 SAP HANA 데이터베이스 복구를 실행합니다.

참고 앞에서 설명한 대로 복구 스크립트 사용은 선택 사항입니다. SnapCenter 클론 생성 워크플로우가 완료된 후에도 수동으로 복구를 수행할 수도 있습니다.
참고 복구 작업을 위한 스크립트는 지우기 로그 작업을 사용하여 SAP HANA 데이터베이스를 스냅샷의 특정 시점으로 복구하고 전달 복구를 실행하지 않습니다. 특정 시점으로 정방향 복구가 필요한 경우 수동으로 복구를 수행해야 합니다. 수동 전달 복구에서는 소스 시스템의 로그 백업을 타겟 호스트에서 사용할 수도 있어야 합니다.

  1. SnapCenter의 작업 세부 정보 화면에 작업 진행률이 표시됩니다. 또한 작업 세부 정보는 데이터베이스 복구를 포함한 전체 런타임이 3분 미만임을 보여 줍니다.

  1. 스크립트의 로그 파일에는 sc-system-refresh 복구 작업에 대해 실행된 여러 단계가 표시됩니다. 스크립트는 시스템 데이터베이스에서 테넌트 목록을 읽고 모든 기존 테넌트의 복구를 실행합니다.

20240425112328###hana-7###sc-system-refresh.sh: Script version: 3.0
hana-7:/mnt/sapcc-share/SAP-System-Refresh # cat sap-system-refresh-QS1.log
20240425112328###hana-7###sc-system-refresh.sh: ******************* Starting script: recovery operation **************************
20240425112328###hana-7###sc-system-refresh.sh: Recover system database.
20240425112328###hana-7###sc-system-refresh.sh: /usr/sap/QS1/HDB11/exe/Python/bin/python /usr/sap/QS1/HDB11/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG"
20240425112346###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is started ....
20240425112347###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112357###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112407###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112417###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112428###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112438###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112448###hana-7###sc-system-refresh.sh: Status: GREEN
20240425112448###hana-7###sc-system-refresh.sh: HANA system database started.
20240425112448###hana-7###sc-system-refresh.sh: Checking connection to system database.
20240425112448###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY 'select * from sys.m_databases;'
DATABASE_NAME,DESCRIPTION,ACTIVE_STATUS,ACTIVE_STATUS_DETAILS,OS_USER,OS_GROUP,RESTART_MODE,FALLBACK_SNAPSHOT_CREATE_TIME
"SYSTEMDB","SystemDB-QS1-11","YES","","","","DEFAULT",?
"QS1","QS1-11","NO","ACTIVE","","","DEFAULT",?
2 rows selected (overall time 16.225 msec; server time 860 usec)
20240425112448###hana-7###sc-system-refresh.sh: Succesfully connected to system database.
20240425112449###hana-7###sc-system-refresh.sh: Tenant databases to recover: QS1
20240425112449###hana-7###sc-system-refresh.sh: Found inactive tenants(QS1) and starting recovery
20240425112449###hana-7###sc-system-refresh.sh: Recover tenant database QS1.
20240425112449###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR QS1 USING SNAPSHOT CLEAR LOG
0 rows affected (overall time 22.138599 sec; server time 22.136268 sec)
20240425112511###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant QS1.
20240425112511###hana-7###sc-system-refresh.sh: Recovery of tenant database QS1 succesfully finished.
20240425112511###hana-7###sc-system-refresh.sh: Status: GREEN
20240425112511###hana-7###sc-system-refresh.sh: ******************* Finished script: recovery operation **************************
hana-7:/mnt/sapcc-share/SAP-System-Refresh

  1. SnapCenter 작업이 완료되면 소스 시스템의 토폴로지 뷰 내에 클론이 표시됩니다.

  1. SAP HANA 데이터베이스가 현재 실행 중입니다.

  2. 타겟 SAP HANA 시스템을 보호하려면 타겟 시스템 리소스를 클릭하여 자동 검색을 실행해야 합니다.

자동 검색 프로세스가 완료되면 새 클론 볼륨이 Storage footprint(저장 공간) 섹션에 나열됩니다.

리소스를 다시 클릭하면 새로 고쳐진 QS1 시스템에 대해 데이터 보호를 구성할 수 있습니다.

오프 사이트 백업 스토리지에서 복제

이 섹션에서는 소스 및 타겟 시스템의 테넌트 이름이 SID와 동일한 SAP HANA 시스템 새로 고침 워크플로우에 대해 설명합니다. 스토리지 클론 생성은 오프 사이트 백업 스토리지에서 실행되고 sc-system-refresh.sh 스크립트를 사용하여 추가로 자동화됩니다.

기본 백업 스토리지 클론 복제와 외부 백업 스토리지 클론 복제 간의 SAP HANA 시스템 업데이트 워크플로우의 유일한 차이점은 SnapCenter에서 스냅샷 백업을 선택한다는 것입니다. 오프사이트 백업 스토리지 클론 복제의 경우, 먼저 보조 백업을 선택한 다음 스냅샷 백업을 선택해야 합니다.

선택한 백업에 대한 보조 저장소 위치가 여러 개인 경우 필요한 대상 볼륨을 선택해야 합니다.

이후의 모든 단계는 운영 스토리지에서 클론 복제를 위한 워크플로우와 동일합니다.

여러 테넌트가 있는 SAP HANA 시스템의 클론 복제

이 섹션에서는 여러 테넌트가 포함된 SAP HANA 시스템 새로 고침 워크플로우에 대해 설명합니다. 스토리지 클론 복제는 기본 스토리지에서 실행되며 스크립트를 사용하여 추가적으로 자동화됩니다. sc-system-refresh.sh

SnapCenter의 필수 단계는 "테넌트 이름이 SID와 같은 운영 스토리지에서 클론 생성" 섹션에 설명된 단계와 동일합니다. 유일한 차이점은 모든 테넌트가 복구되는 스크립트 내의 테넌트 복구 `sc-system-refresh.sh`작업입니다.

20240430070214###hana-7###sc-system-refresh.sh: **********************************************************************************
20240430070214###hana-7###sc-system-refresh.sh: Script version: 3.0
20240430070214###hana-7###sc-system-refresh.sh: ******************* Starting script: recovery operation **************************
20240430070214###hana-7###sc-system-refresh.sh: Recover system database.
20240430070214###hana-7###sc-system-refresh.sh: /usr/sap/QS1/HDB11/exe/Python/bin/python /usr/sap/QS1/HDB11/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG"
[140310725887808, 0.008] >> starting recoverSys (at Tue Apr 30 07:02:15 2024)
[140310725887808, 0.008] args: ()
[140310725887808, 0.008] keys: \{'command': 'RECOVER DATA USING SNAPSHOT CLEAR LOG'}
using logfile /usr/sap/QS1/HDB11/hana-7/trace/backup.log
recoverSys started: ============2024-04-30 07:02:15 ============
testing master: hana-7
hana-7 is master
shutdown database, timeout is 120
stop system
stop system on: hana-7
stopping system: 2024-04-30 07:02:15
stopped system: 2024-04-30 07:02:15
creating file recoverInstance.sql
restart database
restart master nameserver: 2024-04-30 07:02:20
start system: hana-7
sapcontrol parameter: ['-function', 'Start']
sapcontrol returned successfully:
2024-04-30T07:02:32-04:00 P0023828 18f2eab9331 INFO RECOVERY RECOVER DATA finished successfully
recoverSys finished successfully: 2024-04-30 07:02:33
[140310725887808, 17.548] 0
[140310725887808, 17.548] << ending recoverSys, rc = 0 (RC_TEST_OK), after 17.540 secs
20240430070233###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is started ....
20240430070233###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070243###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070253###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070304###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070314###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070314###hana-7###sc-system-refresh.sh: HANA system database started.
20240430070314###hana-7###sc-system-refresh.sh: Checking connection to system database.
20240430070314###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY 'select * from sys.m_databases;'
20240430070314###hana-7###sc-system-refresh.sh: Succesfully connected to system database.
20240430070314###hana-7###sc-system-refresh.sh: Tenant databases to recover: TENANT2
TENANT1
20240430070314###hana-7###sc-system-refresh.sh: Found inactive tenants(TENANT2
TENANT1) and starting recovery
20240430070314###hana-7###sc-system-refresh.sh: Recover tenant database TENANT2.
20240430070314###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR TENANT2 USING SNAPSHOT CLEAR LOG
20240430070335###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant TENANT2.
20240430070335###hana-7###sc-system-refresh.sh: Recovery of tenant database TENANT2 succesfully finished.
20240430070335###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070335###hana-7###sc-system-refresh.sh: Recover tenant database TENANT1.
20240430070335###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR TENANT1 USING SNAPSHOT CLEAR LOG
20240430070349###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant TENANT1.
20240430070350###hana-7###sc-system-refresh.sh: Recovery of tenant database TENANT1 succesfully finished.
20240430070350###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070350###hana-7###sc-system-refresh.sh: ******************* Finished script: recovery operation **************************

클론 삭제 작업

SnapCenter 클론 삭제 작업을 사용하여 타겟 시스템을 정리하면 새로운 SAP HANA 시스템 새로 고침 작업이 시작됩니다.

타겟 SAP HANA 시스템이 SnapCenter에서 보호되어 있는 경우 먼저 보호를 제거해야 합니다. 타겟 시스템의 토폴로지 뷰에서 Remove Protection을 클릭합니다.

이제 클론 삭제 워크플로우가 다음 단계로 실행됩니다.

  1. 소스 시스템의 토폴로지 뷰 내에서 클론을 선택하고 Delete를 클릭합니다.

  1. 필요한 명령줄 옵션과 함께 사전 클론 생성 및 마운트 해제 스크립트를 입력합니다.

  1. SnapCenter의 작업 세부 정보 화면에 작업 진행률이 표시됩니다.

  1. 스크립트의 로그 파일에는 sc-system-refresh 종료 및 마운트 해제 작업 단계가 표시됩니다.

20240425111042###hana-7###sc-system-refresh.sh: **********************************************************************************
20240425111042###hana-7###sc-system-refresh.sh: Script version: 3.0
20240425111042###hana-7###sc-system-refresh.sh: ******************* Starting script: shutdown operation **************************
20240425111042###hana-7###sc-system-refresh.sh: Stopping HANA database.
20240425111042###hana-7###sc-system-refresh.sh: sapcontrol -nr 11 -function StopSystem HDB
25.04.2024 11:10:42
StopSystem
OK
20240425111042###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is stopped ....
20240425111042###hana-7###sc-system-refresh.sh: Status: GREEN
20240425111052###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111103###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111113###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111123###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111133###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111144###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111154###hana-7###sc-system-refresh.sh: Status: GRAY
20240425111154###hana-7###sc-system-refresh.sh: SAP HANA database is stopped.
20240425111154###hana-7###sc-system-refresh.sh: ******************* Finished script: shutdown operation **************************

  1. 이제 SnapCenter 클론 생성 작업을 사용하여 SAP HANA 새로 고침 작업을 다시 시작할 수 있습니다.

클론 분할 작업을 통해 SAP HANA 시스템 업데이트

시스템 업데이트 작업의 타겟 시스템을 더 오랜 기간 사용하도록 계획한 경우, 시스템 업데이트 작업의 일부로 FlexClone 볼륨을 분할하는 것이 좋습니다.

참고 클론 분할 작업은 클론된 볼륨의 사용을 차단하지 않으므로 SAP HANA 데이터베이스가 사용 중인 동안 언제든지 실행할 수 있습니다.
참고 Azure NetApp Files에서는 클론 분할 작업을 사용할 수 없습니다. Azure NetApp Files는 생성 후 클론을 항상 분할하기 때문입니다.

SnapCenter의 클론 분할 워크플로는 클론을 선택하고 클론 분할을 클릭하여 소스 시스템의 토폴로지 뷰에서 시작됩니다.

분할 볼륨에 필요한 용량에 대한 정보를 제공하는 미리 보기가 다음 화면에 표시됩니다.

SnapCenter 작업 로그에는 클론 분할 작업의 진행률이 표시됩니다.

SnapCenter의 리소스 보기에서 대상 시스템 QS1이 이제 더 이상 클론 리소스로 표시되지 않습니다. 소스 시스템의 토폴로지 뷰로 돌아가면 더 이상 클론이 표시되지 않습니다. 분할된 볼륨은 이제 소스 시스템의 스냅샷 백업과 독립적입니다.

클론 분할 작업 후 새로 고침 워크플로우가 클론 분할 없는 작업과 약간 다릅니다. 클론 분할 작업 후에는 타겟 데이터 볼륨이 더 이상 FlexClone 볼륨이 아니기 때문에 클론 삭제 작업이 필요하지 않습니다.

워크플로는 다음 단계로 구성됩니다.

  1. 타겟 SAP HANA 시스템이 SnapCenter에서 보호되어 있는 경우 먼저 보호를 제거해야 합니다.

  2. SAP HANA 데이터베이스를 종료하고 데이터 볼륨을 마운트 해제해야 하며 SnapCenter에서 생성한 fstab 항목을 제거해야 합니다. 이러한 단계는 수동으로 실행해야 합니다.

  3. 이제 앞의 섹션에 설명된 대로 SnapCenter 클론 생성 워크플로우를 실행할 수 있습니다.

  4. 업데이트 작업 후에도 이전 타겟 데이터 볼륨이 계속 존재하므로 ONTAP System Manager와 같은 를 사용하여 수동으로 삭제해야 합니다.

PowerShell 스크립트를 사용한 SnapCenter 워크플로우 자동화

이전 섹션에서는 SnapCenter UI를 사용하여 다양한 워크플로우를 실행했습니다. PowerShell 스크립트나 REST API 호출을 통해 모든 워크플로우를 실행하여 추가적으로 자동화할 수 있습니다. 다음 섹션에서는 다음 워크플로우에 대한 기본 PowerShell 스크립트 예제를 설명합니다.

  • 클론 생성

  • 클론을 삭제합니다

    참고 예제 스크립트는 있는 그대로 제공되며 NetApp에서 지원하지 않습니다.

PowerShell 명령 창에서 모든 스크립트를 실행해야 합니다. 스크립트를 실행하기 전에 'Open-SmConnection' 명령을 사용하여 SnapCenter 서버에 연결해야 합니다.

클론 생성

아래의 간단한 스크립트는 PowerShell 명령을 사용하여 SnapCenter 클론 생성 작업을 실행하는 방법을 보여 줍니다. SnapCenter의 New-SmClone 명령은 실습 환경에 필요한 명령줄 옵션과 앞에서 설명한 자동화 스크립트를 사용하여 실행됩니다.

$BackupName='SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
$JobInfo=New-SmClone -AppPluginCode hana -BackupName $BackupName -Resources @\{"Host"="hana-1.sapcc.stl.netapp.com";"UID"="MDC\SS1"} -CloneToInstance hana-7.sapcc.stl.netapp.com -postclonecreatecommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh recover' -NFSExportIPs 192.168.175.75 -CloneUid 'MDC\QS1'
# Get JobID of clone create job
$Job=Get-SmJobSummaryReport | ?\{$_.JobType -eq "Clone" } | ?\{$_.JobName -Match $BackupName} | ?\{$_.Status -eq "Running"}
$JobId=$Job.SmJobId
Get-SmJobSummaryReport -JobId $JobId
# Wait until job is finished
do \{ $Job=Get-SmJobSummaryReport -JobId $JobId; write-host $Job.Status; sleep 20 } while ( $Job.Status -Match "Running" )
Write-Host " "
Get-SmJobSummaryReport -JobId $JobId
Write-Host "Clone create job has been finshed."

화면 출력에는 클론 생성 PowerShell 스크립트의 실행이 표시됩니다.

PS C:\Windows\system32> C:\NetApp\clone-create.ps1
SmJobId : 110382
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 9:55:34 AM
JobEndDateTime :
JobDuration :
JobName : Clone from backup 'SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
JobDescription :
Status : Running
IsScheduled : False
JobError :
JobType : Clone
PolicyName :
JobResultData :
Running
Running
Running
Running
Running
Running
Running
Running
Running
Running
Completed
SmJobId : 110382
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 9:55:34 AM
JobEndDateTime : 6/26/2024 9:58:50 AM
JobDuration : 00:03:16.6889170
JobName : Clone from backup 'SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
JobDescription :
Status : Completed
IsScheduled : False
JobError :
JobType : Clone
PolicyName :
JobResultData :
Clone create job has been finshed.

클론을 삭제합니다

아래의 간단한 스크립트는 PowerShell 명령을 사용하여 SnapCenter 클론 삭제 작업을 실행하는 방법을 보여 줍니다. SnapCenter의 'Remove-SmClone' 명령은 실습 환경에 필요한 명령줄 옵션과 앞에서 설명한 자동화 스크립트를 사용하여 실행됩니다.

$CloneInfo=Get-SmClone |?\{$_.CloneName -Match "hana-1_sapcc_stl_netapp_com_hana_MDC_SS1" }
$JobInfo=Remove-SmClone -CloneName $CloneInfo.CloneName -PluginCode hana -PreCloneDeleteCommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh shutdown QS1' -UnmountCommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh umount QS1' -Confirm: $False
Get-SmJobSummaryReport -JobId $JobInfo.Id
# Wait until job is finished
do \{ $Job=Get-SmJobSummaryReport -JobId $JobInfo.Id; write-host $Job.Status; sleep 20 } while ( $Job.Status -Match "Running" )
Write-Host " "
Get-SmJobSummaryReport -JobId $JobInfo.Id
Write-Host "Clone delete job has been finshed."
PS C:\NetApp>

화면 출력에는 clone –delete.ps1 PowerShell 스크립트의 실행이 표시됩니다.

PS C:\Windows\system32> C:\NetApp\clone-delete.ps1
SmJobId : 110386
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 10:01:33 AM
JobEndDateTime :
JobDuration :
JobName : Deleting clone 'hana-1_sapcc_stl_netapp_com_hana_MDC_SS1__clone__110382_MDC_SS1_04-22-2024_09.54.34'
JobDescription :
Status : Running
IsScheduled : False
JobError :
JobType : DeleteClone
PolicyName :
JobResultData :
Running
Running
Running
Running
Completed
SmJobId : 110386
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 10:01:33 AM
JobEndDateTime : 6/26/2024 10:02:38 AM
JobDuration : 00:01:05.5658860
JobName : Deleting clone 'hana-1_sapcc_stl_netapp_com_hana_MDC_SS1__clone__110382_MDC_SS1_04-22-2024_09.54.34'
JobDescription :
Status : Completed
IsScheduled : False
JobError :
JobType : DeleteClone
PolicyName :
JobResultData :
Clone delete job has been finshed.
PS C:\Windows\system32>