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

SnapCenter 개념 및 모범 사례

기여자

이 섹션에서는 SAP HANA 리소스 구성 및 구축과 관련된 SnapCenter 개념 및 모범 사례에 대해 설명합니다.

SAP HANA 리소스 구성 옵션 및 개념

SnapCenter를 사용하면 두 가지 다른 접근 방식으로 SAP HANA 데이터베이스 리소스 구성을 수행할 수 있습니다.

  • * 수동 리소스 구성 * HANA 리소스 및 스토리지 설치 공간 정보는 수동으로 제공해야 합니다.

  • * HANA 리소스 자동 검색 * 자동 검색 기능은 SnapCenter에서 HANA 데이터베이스 구성을 간소화하고 자동 복원 및 복구를 지원합니다.

SnapCenter에서 자동으로 검색된 HANA 데이터베이스 리소스만 자동 복원 및 복구에 사용할 수 있다는 점을 이해하는 것이 중요합니다. SnapCenter에서 수동으로 구성된 HANA 데이터베이스 리소스는 SnapCenter에서 복원 작업 후에 수동으로 복구해야 합니다.

반면에, SnapCenter를 사용한 자동 검색은 모든 HANA 아키텍처 및 인프라 구성에 대해 지원되지 않습니다. 따라서 HANA 환경을 위해서는 일부 HANA 시스템(HANA 다중 호스트 시스템)에 수동 리소스 구성이 필요하며 다른 모든 시스템은 자동 검색을 사용하여 구성할 수 있는 혼합 방식이 필요할 수 있습니다.

자동 검색 및 자동 복원 및 복구는 데이터베이스 호스트에서 OS 명령을 실행하는 기능에 따라 다릅니다. 이러한 작업의 예로는 파일 시스템 및 스토리지 설치 공간 검색, 마운트 해제, 마운트 또는 LUN 검색 작업이 있습니다. 이러한 작업은 SnapCenter Linux 플러그인을 통해 실행되며, HANA 플러그인과 함께 자동으로 구축됩니다. 따라서 자동 검색뿐만 아니라 자동 복원 및 복구를 사용하려면 데이터베이스 호스트에 HANA 플러그인을 구축해야 합니다. 데이터베이스 호스트에 HANA 플러그인을 구축한 후 자동 검색을 비활성화할 수도 있습니다. 이 경우 리소스는 수동으로 구성된 리소스가 됩니다.

다음 그림은 종속성을 요약합니다. HANA 구축 옵션에 대한 자세한 내용은 “SAP HANA 플러그인의 구축 옵션” 섹션에서 다룹니다.

오류: 그래픽 이미지가 없습니다
참고 HANA 및 Linux 플러그인은 현재 인텔 기반 시스템에서만 사용할 수 있습니다. HANA 데이터베이스가 IBM Power Systems에서 실행되는 경우 중앙 HANA 플러그인 호스트를 사용해야 합니다.

자동 검색 및 자동 복구를 지원하는 HANA 아키텍처

SnapCenter를 사용하면 대부분의 HANA 구성에서 자동 검색 및 자동 복원 및 복구가 지원됩니다. 단, HANA 다중 호스트 시스템에는 수동 구성이 필요합니다.

다음 표에는 자동 검색에 대해 지원되는 HANA 구성이 나와 있습니다.

HANA 플러그인 설치 위치: HANA 아키텍처 HANA 시스템 구성 검토할 수 있습니다

HANA 데이터베이스 호스트

단일 호스트

  • HANA 단일 컨테이너

  • 단일 또는 다중 테넌트가 포함된 SAP HANA 멀티 테넌트 데이터베이스 컨테이너(MDC

  • HANA 시스템 복제

  • NFS를 이용한 베어 메탈

  • Linux LVM(Logical Volume Manager) 포함 또는 미포함 XFS 및 FC를 사용하는 베어 메탈

  • 직접 OS NFS 마운트를 지원하는 VMware

참고 여러 테넌트가 포함된 HANA MDC 시스템은 자동 검색을 지원하지만 현재 SnapCenter 릴리즈를 사용한 자동 복구 및 복구는 지원하지 않습니다.

수동 HANA 리소스 구성에 지원되는 HANA 아키텍처

모든 HANA 아키텍처에 대해 HANA 리소스를 수동으로 구성할 수 있지만 중앙 HANA 플러그인 호스트가 필요합니다. 중앙 플러그인 호스트는 SnapCenter 서버 자체 또는 별도의 Linux 또는 Windows 호스트일 수 있습니다.

참고 HANA 플러그인을 HANA 데이터베이스 호스트에 구축하면 기본적으로 리소스가 자동으로 검색됩니다. 예를 들어, 활성화된 HANA 시스템 복제가 있는 데이터베이스 호스트 및 자동 검색이 지원되지 않는 SnapCenter 릴리스 < 4.6과 같이 플러그인을 배포할 수 있도록 개별 호스트에 대해 자동 검색을 비활성화할 수 있습니다. 자세한 내용은 섹션을 참조하십시오 "“HANA 플러그인 호스트에서 자동 검색을 사용하지 않도록 설정합니다.”"

다음 표에는 수동 HANA 리소스 구성에 지원되는 HANA 구성이 나와 있습니다.

HANA 플러그인 설치 위치: HANA 아키텍처 HANA 시스템 구성 검토할 수 있습니다

중앙 플러그인 호스트(SnapCenter 서버 또는 별도의 Linux 호스트)

단일 또는 다중 호스트

  • HANA 단일 컨테이너

  • 하나 또는 여러 테넌트가 포함된 HANA MDC

  • HANA 시스템 복제

  • NFS를 이용한 베어 메탈

  • Linux LVM을 사용하거나 사용하지 않는 XFS 및 FC를 사용하는 베어 메탈

  • 직접 OS NFS 마운트를 지원하는 VMware

SAP HANA 플러그인의 구축 옵션

다음 그림에서는 SnapCenter Server와 SAP HANA 데이터베이스 간의 논리적 뷰 및 통신을 보여 줍니다.

SnapCenter 서버는 SAP HANA 플러그인을 통해 SAP HANA 데이터베이스와 통신합니다. SAP HANA 플러그인은 SAP HANA hdbsql 클라이언트 소프트웨어를 사용하여 SAP HANA 데이터베이스에 대한 SQL 명령을 실행합니다. SAP HANA hdbuserstore는 SAP HANA 데이터베이스에 액세스하기 위한 사용자 자격 증명, 호스트 이름 및 포트 정보를 제공하는 데 사용됩니다.

오류: 그래픽 이미지가 없습니다
참고 hdbuserstore 구성 툴을 포함하는 SAP HANA 플러그인 및 SAP hdbsql 클라이언트 소프트웨어를 동일한 호스트에 함께 설치해야 합니다.

호스트는 SnapCenter 서버 자체, 별도의 중앙 플러그인 호스트 또는 개별 SAP HANA 데이터베이스 호스트가 될 수 있습니다.

SnapCenter 서버 고가용성

SnapCenter는 2노드 HA 구성으로 설정할 수 있습니다. 이러한 구성에서는 활성 SnapCenter 호스트를 가리키는 가상 IP 주소를 사용하여 Active/Passive 모드에서 로드 밸런서(예: F5)가 사용됩니다. SnapCenter 저장소(MySQL 데이터베이스)는 두 호스트 간에 SnapCenter에 의해 복제되므로 SnapCenter 데이터가 항상 동기화됩니다.

HANA 플러그인이 SnapCenter 서버에 설치된 경우 SnapCenter 서버 HA는 지원되지 않습니다. HA 구성에서 SnapCenter를 설정하려는 경우 SnapCenter 서버에 HANA 플러그인을 설치하지 마십시오. SnapCenter HA에 대한 자세한 내용은 여기에서 확인할 수 있습니다 "NetApp 기술 자료 페이지를 참조하십시오".

SnapCenter Server를 중앙 HANA 플러그인 호스트로 사용합니다

다음 그림에서는 SnapCenter 서버가 중앙 플러그인 호스트로 사용되는 구성을 보여 줍니다. SAP HANA 플러그인 및 SAP hdbsql 클라이언트 소프트웨어는 SnapCenter 서버에 설치됩니다.

오류: 그래픽 이미지가 없습니다

HANA 플러그인은 네트워크를 통해 hdbclient를 사용하여 관리형 HANA 데이터베이스와 통신할 수 있으므로 개별 HANA 데이터베이스 호스트에 SnapCenter 구성 요소를 설치할 필요가 없습니다. SnapCenter는 모든 사용자 저장소 키가 관리 데이터베이스에 대해 구성된 중앙 HANA 플러그인 호스트를 사용하여 HANA 데이터베이스를 보호할 수 있습니다.

반면, 자동 검색, 복원 및 복구 자동화, SAP 시스템 새로 고침 작업을 위한 향상된 워크플로우 자동화에는 SnapCenter 구성 요소를 데이터베이스 호스트에 설치해야 합니다. 중앙 HANA 플러그인 호스트를 사용하는 경우 이러한 기능을 사용할 수 없습니다.

또한, SnapCenter 서버에 HANA 플러그인이 설치되어 있는 경우에는 빌드 내 HA 기능을 사용하는 SnapCenter 서버의 고가용성도 사용할 수 없습니다. SnapCenter 서버가 VMware 클러스터 내의 VM에서 실행 중인 경우 VMware HA를 사용하여 고가용성을 달성할 수 있습니다.

호스트를 중앙 HANA 플러그인 호스트로 분리합니다

다음 그림에서는 별도의 Linux 호스트를 중앙 플러그인 호스트로 사용하는 구성을 보여 줍니다. 이 경우 Linux 호스트에 SAP HANA 플러그인 및 SAP hdbsql 클라이언트 소프트웨어가 설치됩니다.

참고 별도의 중앙 플러그인 호스트도 Windows 호스트일 수 있습니다.
오류: 그래픽 이미지가 없습니다

이전 섹션에서 설명한 기능 가용성에 대한 동일한 제한은 별도의 중앙 플러그인 호스트에도 적용됩니다.

그러나 이 배포 옵션을 사용하면 SnapCenter 서버를 빌드 내 HA 기능으로 구성할 수 있습니다. 예를 들어, Linux 클러스터 솔루션을 사용하는 경우 중앙 플러그인 호스트도 HA여야 합니다.

개별 HANA 데이터베이스 호스트에 구축된 HANA 플러그인

다음 그림에서는 각 SAP HANA 데이터베이스 호스트에 SAP HANA 플러그인이 설치되는 구성을 보여 줍니다.

오류: 그래픽 이미지가 없습니다

HANA 플러그인을 각 개별 HANA 데이터베이스 호스트에 설치하면 자동 검색, 자동 복원, 복구와 같은 모든 기능을 사용할 수 있습니다. 또한 SnapCenter 서버는 HA 구성으로 설정할 수 있습니다.

혼합 HANA 플러그인 구축

이 섹션의 시작 부분에서 설명한 대로 다중 호스트 시스템과 같은 일부 HANA 시스템 구성에는 중앙 플러그인 호스트가 필요합니다. 따라서 대부분의 SnapCenter 구성에서는 HANA 플러그인을 혼합해서 구축해야 합니다.

자동 검색이 지원되는 모든 HANA 시스템 구성에 대해 HANA 데이터베이스 호스트에 HANA 플러그인을 구축하는 것이 좋습니다. 다중 호스트 구성과 같은 다른 HANA 시스템은 중앙 HANA 플러그인 호스트를 통해 관리해야 합니다.

다음 두 그림에서는 SnapCenter 서버 또는 별도의 Linux 호스트를 중앙 플러그인 호스트로 사용한 혼합 플러그인 구축을 보여 줍니다. 이 두 구축 환경 간의 유일한 차이점은 선택적 HA 구성입니다.

오류: 그래픽 이미지가 없습니다
오류: 그래픽 이미지가 없습니다

요약 및 권장 사항

일반적으로 NetApp은 사용 가능한 모든 SnapCenter HANA 기능을 지원하고 워크플로우 자동화를 향상할 수 있도록 각 SAP HANA 호스트에 HANA 플러그인을 구축할 것을 권장합니다.

참고 HANA 및 Linux 플러그인은 현재 인텔 기반 시스템에서만 사용할 수 있습니다. HANA 데이터베이스가 IBM Power Systems에서 실행되는 경우 중앙 HANA 플러그인 호스트를 사용해야 합니다.

HANA 다중 호스트 구성과 같이 자동 검색이 지원되지 않는 HANA 구성의 경우 추가 중앙 HANA 플러그인 호스트를 구성해야 합니다. VMware HA를 SnapCenter HA에 활용할 수 있는 경우 중앙 플러그인 호스트가 SnapCenter 서버가 될 수 있습니다. SnapCenter In-build HA 기능을 사용하려면 별도의 Linux 플러그인 호스트를 사용하십시오.

다음 표에는 다양한 구축 옵션이 요약되어 있습니다.

구축 옵션 종속성

SnapCenter 서버에 설치된 중앙 HANA 플러그인 호스트 플러그인

장점: * 단일 HANA 플러그인, 중앙 HDB 사용자 저장소 구성 * 개별 HANA 데이터베이스 호스트에 필요한 SnapCenter 소프트웨어 구성 요소 없음 * 모든 HANA 아키텍처 지원 단점: * 수동 리소스 구성 * 수동 복구 * 단일 테넌트 복원 지원 없음 * 중앙 플러그인 호스트에서 사전 및 사후 스크립트 단계가 실행됨 * 빌드의 SnapCenter 고가용성 지원되지 않음 * SID와 테넌트 이름의 조합은 관리되는 모든 HANA 데이터베이스 * 로그에서 고유해야 합니다 모든 관리형 HANA 데이터베이스에 대해 백업 보존 관리 활성화/비활성화

별도의 Linux 또는 Windows 서버에 설치된 중앙 HANA 플러그인 호스트 플러그인

장점: * 단일 HANA 플러그인, 중앙 HDB 사용자 저장소 구성 * 개별 HANA 데이터베이스 호스트에 필요한 SnapCenter 소프트웨어 구성 요소 없음 * 모든 HANA 아키텍처 지원 * 빌드에 구축된 SnapCenter 고가용성 지원 단점: * 수동 리소스 구성 * 수동 복구 * 단일 테넌트 복원 지원 없음 * 중앙 플러그인 호스트에서 사전 및 사후 스크립트 단계가 실행됨 * SID와 테넌트 이름의 조합은 관리되는 모든 HANA 데이터베이스에서 고유해야 함 * 관리되는 모든 데이터베이스에 대해 로그 백업 보존 관리 활성화/비활성화 HANA 데이터베이스

HANA 데이터베이스 서버에 설치된 개별 HANA 플러그인 호스트 플러그인

장점: * HANA 리소스 자동 검색 * 자동 복원 및 복구 * 단일 테넌트 복원 * SAP 시스템 새로 고침을 위한 사전 및 사후 스크립트 자동화 * 빌드의 SnapCenter 고가용성 지원 * 개별 HANA 데이터베이스별로 로그 백업 보존 관리 활성화/비활성화 가능 단점: * 일부 HANA 아키텍처에는 지원되지 않습니다. HANA 다중 호스트 시스템을 위한 추가 중앙 플러그인 호스트가 필요합니다. 각 HANA 데이터베이스 호스트에 * HANA 플러그인을 구축해야 합니다

데이터 보호 전략

SnapCenter 및 SAP HANA 플러그인을 구성하기 전에 다양한 SAP 시스템의 RTO 및 RPO 요구사항을 기준으로 데이터 보호 전략을 정의해야 합니다.

일반적인 접근 방식은 운영, 개발, 테스트 또는 샌드박스 시스템과 같은 시스템 유형을 정의하는 것입니다. 동일한 시스템 유형의 모든 SAP 시스템은 일반적으로 동일한 데이터 보호 매개 변수를 사용합니다.

정의해야 하는 매개 변수는 다음과 같습니다.

  • Snapshot 백업을 얼마나 자주 실행해야 합니까?

  • Snapshot 복사본 백업을 기본 스토리지 시스템에 얼마나 오래 보관해야 합니까?

  • 블록 무결성 검사를 얼마나 자주 실행해야 합니까?

  • 기본 백업을 오프 사이트 백업 사이트로 복제해야 합니까?

  • 백업을 오프 사이트 백업 스토리지에 얼마나 오래 보관해야 합니까?

다음 표에서는 시스템 유형의 프로덕션, 개발 및 테스트에 대한 데이터 보호 매개 변수의 예를 보여 줍니다. 운영 시스템의 경우 백업 빈도가 높아지면 백업을 매일 한 번씩 오프사이트 백업 사이트로 복제합니다. 테스트 시스템은 요구 사항이 낮고 백업 복제가 필요하지 않습니다.

매개 변수 운영 시스템 개발 시스템 시스템을 테스트합니다

백업 빈도

4시간마다

4시간마다

4시간마다

기본 보존

2일

2일

2일

블록 무결성 검사

일주일에 한 번

일주일에 한 번

아니요

오프 사이트 백업 사이트로 복제

하루에 한 번

하루에 한 번

아니요

오프 사이트 백업 보존

2주

2주

해당 없음

다음 표에는 데이터 보호 매개 변수에 대해 구성해야 하는 정책이 나와 있습니다.

매개 변수 PolicyLocalSnap 을 참조하십시오 PolicyLocalSnapAndSnapVault를 사용하여 정책 구성 및 정책 구성 PolicyBlockIntegrityCheck을 참조하십시오

백업 유형

스냅샷 기반

스냅샷 기반

파일 기반

일정 빈도

매시간

매일

매주

기본 보존

개수 = 12

개수 = 3

개수 = 1

SnapVault 복제

아니요

해당 없음

LocalSnapshot 정책은 운영, 개발 및 테스트 시스템에 사용되어 2일 동안 로컬 Snapshot 백업을 보존합니다.

리소스 보호 구성에서 스케줄은 시스템 유형에 따라 다르게 정의됩니다.

  • * 생산. * 4시간마다 예약.

  • * 개발. * 4시간마다 예약.

  • * 테스트 * 4시간마다 예약.

운영 및 개발 시스템에서는 로컬 SnapAndSnapVault 정책을 사용하여 오프사이트 백업 스토리지에 대한 일일 복제를 수행합니다.

리소스 보호 구성에서 일정은 운영 및 개발에 대해 정의됩니다.

  • * 생산. * 매일 일정을 예약합니다.

  • * 개발. * 매일 일정을 예약합니다.

운영 및 개발 시스템에서 파일 기반 백업을 사용하여 주별 블록 무결성 검사를 수행하는 데 BlockIntegrityCheck 정책이 사용됩니다.

리소스 보호 구성에서 일정은 운영 및 개발에 대해 정의됩니다.

  • * 생산. * 매주 일정을 예약합니다.

  • * 개발. * 매주 일정을 예약합니다.

오프 사이트 백업 정책을 사용하는 각 개별 SAP HANA 데이터베이스에 대해 스토리지 계층에 보호 관계를 구성해야 합니다. 보호 관계는 복제할 볼륨과 오프 사이트 백업 스토리지의 백업 보존을 정의합니다.

이 예에서는 각 운영 및 개발 시스템에 대해 오프사이트 백업 스토리지에서 2주 동안의 보존 기간을 정의합니다.

참고 이 예에서는 SAP HANA 데이터베이스 리소스 및 비 데이터 볼륨 리소스에 대한 보호 정책과 보존 정책이 서로 다릅니다.

백업 작업

SAP는 HANA 2.0 SPS4를 사용하는 MDC 다중 테넌트 시스템에 대한 스냅샷 백업 지원을 도입했습니다. SnapCenter는 여러 테넌트가 있는 HANA MDC 시스템의 스냅샷 백업 작업을 지원합니다. SnapCenter는 또한 HANA MDC 시스템의 두 가지 다른 복원 작업을 지원합니다. 전체 시스템, System DB 및 모든 테넌트를 복원하거나 단일 테넌트만 복원할 수 있습니다. SnapCenter에서 이러한 작업을 실행할 수 있도록 하기 위한 몇 가지 필수 구성 요소가 있습니다.

MDC 시스템에서 테넌트 구성이 반드시 정적이지 않을 수 있습니다. 테넌트를 추가하거나 테넌트를 삭제할 수 있습니다. SnapCenter는 HANA 데이터베이스를 SnapCenter에 추가할 때 검색된 구성을 사용할 수 없습니다. SnapCenter는 백업 작업이 실행되는 시점에 사용 가능한 테넌트를 파악해야 합니다.

단일 테넌트 복원 작업을 활성화하려면 SnapCenter는 각 스냅샷 백업에 어떤 테넌트가 포함되어 있는지 알고 있어야 합니다. 또한 스냅샷 백업에 포함된 각 테넌트에 속한 파일과 디렉토리도 알아야 합니다.

따라서 각 백업 작업에서 워크플로우의 첫 번째 단계는 테넌트 정보를 가져오는 것입니다. 여기에는 테넌트 이름과 해당 파일 및 디렉토리 정보가 포함됩니다. 단일 테넌트 복원 작업을 지원할 수 있으려면 이 데이터를 스냅샷 백업 메타데이터에 저장해야 합니다. 다음 단계는 스냅샷 백업 작업 자체입니다. 이 단계에서는 HANA 백업 저장점, 스토리지 스냅샷 백업 및 스냅샷 작업을 닫기 위한 SQL 명령을 트리거하는 SQL 명령이 포함됩니다. close 명령을 사용하면 HANA 데이터베이스가 시스템 DB 및 각 테넌트의 백업 카탈로그를 업데이트합니다.

참고 하나 이상의 테넌트가 중지된 경우 SAP는 MDC 시스템에 대한 스냅샷 백업 작업을 지원하지 않습니다.

데이터 백업 및 HANA 백업 카탈로그 관리의 보존 관리를 위해 SnapCenter는 첫 번째 단계에서 식별된 시스템 데이터베이스 및 모든 테넌트 데이터베이스에 대해 카탈로그 삭제 작업을 실행해야 합니다. 로그 백업과 마찬가지로 SnapCenter 워크플로도 백업 작업의 일부인 각 테넌트에서 작동해야 합니다.

다음 그림에서는 백업 워크플로우의 개요를 보여 줍니다.

오류: 그래픽 이미지가 없습니다

HANA 데이터베이스의 Snapshot 백업을 위한 백업 워크플로우

SnapCenter는 SAP HANA 데이터베이스를 다음 순서로 백업합니다.

  1. SnapCenter는 HANA 데이터베이스에서 테넌트 목록을 읽습니다.

  2. SnapCenter는 HANA 데이터베이스에서 각 테넌트의 파일과 디렉토리를 읽습니다.

  3. 테넌트 정보는 이 백업 작업을 위한 SnapCenter 메타데이터에 저장됩니다.

  4. SnapCenter는 SAP HANA 글로벌 동기화 백업 저장 지점을 트리거하여 지속성 계층에서 일관된 데이터베이스 이미지를 생성합니다.

    참고 SAP HANA MDC 단일 또는 다중 테넌트 시스템의 경우 시스템 데이터베이스와 각 테넌트 데이터베이스에 대해 동기화된 글로벌 백업 세이브 포인트가 생성됩니다.
  5. SnapCenter는 리소스에 대해 구성된 모든 데이터 볼륨에 대해 스토리지 스냅샷 복사본을 생성합니다. 단일 호스트 HANA 데이터베이스의 예로 데이터 볼륨은 하나만 있습니다. SAP HANA 다중 호스트 데이터베이스에는 여러 데이터 볼륨이 있습니다.

  6. SnapCenter는 스토리지 스냅샷 백업을 SAP HANA 백업 카탈로그에 등록합니다.

  7. SnapCenter는 SAP HANA 백업 저장 지점을 삭제합니다.

  8. SnapCenter는 리소스에 구성된 모든 데이터 볼륨에 대해 SnapVault 또는 SnapMirror 업데이트를 시작합니다.

    참고 이 단계는 선택한 정책에 SnapVault 또는 SnapMirror 복제가 포함된 경우에만 실행됩니다.
  9. SnapCenter은 운영 스토리지의 백업에 정의된 보존 정책을 기반으로 데이터베이스와 SAP HANA 백업 카탈로그에서 스토리지 스냅샷 복사본 및 백업 항목을 삭제합니다. HANA 백업 카탈로그 작업은 시스템 데이터베이스 및 모든 테넌트에 대해 수행됩니다.

    참고 보조 스토리지에서 백업을 계속 사용할 수 있는 경우 SAP HANA 카탈로그 항목이 삭제되지 않습니다.
  10. SnapCenter는 SAP HANA 백업 카탈로그에 식별된 가장 오래된 데이터 백업보다 오래된 파일 시스템과 SAP HANA 백업 카탈로그에 있는 모든 로그 백업을 삭제합니다. 이러한 작업은 시스템 데이터베이스 및 모든 테넌트에 대해 수행됩니다.

    참고 이 단계는 로그 백업 관리 기능이 비활성화되지 않은 경우에만 실행됩니다.

블록 무결성 검사 작업을 위한 백업 워크플로우

SnapCenter는 다음 순서로 블록 무결성 검사를 실행합니다.

  1. SnapCenter는 HANA 데이터베이스에서 테넌트 목록을 읽습니다.

  2. SnapCenter는 시스템 데이터베이스와 각 테넌트에 대해 파일 기반 백업 작업을 트리거합니다.

  3. SnapCenter는 블록 무결성 검사 작업에 정의된 보존 정책을 기반으로 데이터베이스, 파일 시스템 및 SAP HANA 백업 카탈로그에서 파일 기반 백업을 삭제합니다. 파일 시스템에서 백업 삭제 및 HANA 백업 카탈로그 작업은 시스템 데이터베이스 및 모든 테넌트에 대해 수행됩니다.

  4. SnapCenter는 SAP HANA 백업 카탈로그에 식별된 가장 오래된 데이터 백업보다 오래된 파일 시스템과 SAP HANA 백업 카탈로그에 있는 모든 로그 백업을 삭제합니다. 이러한 작업은 시스템 데이터베이스 및 모든 테넌트에 대해 수행됩니다.

참고 이 단계는 로그 백업 관리 기능이 비활성화되지 않은 경우에만 실행됩니다.

백업 보존 관리 및 데이터 및 로그 백업 관리

데이터 백업 보존 관리 및 로그 백업 정리정돈 은 보존 관리를 포함하여 5가지 주요 영역으로 나눌 수 있습니다.

  • 운영 스토리지의 로컬 백업

  • 파일 기반 백업

  • 보조 스토리지의 백업입니다

  • SAP HANA 백업 카탈로그 내의 데이터 백업

  • SAP HANA 백업 카탈로그 및 파일 시스템에 로그 백업

다음 그림에서는 다양한 워크플로우와 각 작업의 종속 관계를 간략하게 보여 줍니다. 다음 섹션에서는 다양한 작업에 대해 자세히 설명합니다.

오류: 그래픽 이미지가 없습니다

운영 스토리지에서 로컬 백업의 보존 관리

SnapCenter는 SnapCenter 백업 정책에 정의된 보존에 따라 운영 스토리지와 SnapCenter 저장소에서 스냅샷 복사본을 삭제하여 SAP HANA 데이터베이스 백업 및 비 데이터 볼륨 백업의 내부 관리를 처리합니다.

보존 관리 로직은 SnapCenter의 각 백업 워크플로우에서 실행됩니다.

참고 SnapCenter는 예약된 백업과 필요 시 백업 모두에 대해 개별적으로 보존 관리를 처리한다는 점에 유의하십시오.

SnapCenter에서 운영 스토리지의 로컬 백업을 수동으로 삭제할 수도 있습니다.

파일 기반 백업의 보존 관리

SnapCenter는 SnapCenter 백업 정책에 정의된 보존에 따라 파일 시스템에서 백업을 삭제하여 파일 기반 백업의 관리 작업을 처리합니다.

보존 관리 로직은 SnapCenter의 각 백업 워크플로우에서 실행됩니다.

참고 SnapCenter는 예약된 백업 또는 필요 시 백업을 위해 개별적으로 보존 관리를 처리한다는 점에 유의하십시오.

보조 스토리지에서 백업의 보존 관리

보조 스토리지에서 백업의 보존 관리는 ONTAP 보호 관계에 정의된 보존 기간을 기준으로 ONTAP에서 처리합니다.

SnapCenter 리포지토리의 보조 스토리지에서 이러한 변경 내용을 동기화하기 위해 SnapCenter는 예약된 정리 작업을 사용합니다. 이 정리 작업은 모든 보조 스토리지 백업을 SnapCenter 리포지토리와 동기화하여 모든 SnapCenter 플러그인 및 모든 리소스를 제공합니다.

정리 작업은 기본적으로 매주 한 번 예약됩니다. 이 주별 스케줄은 보조 스토리지에서 이미 삭제된 백업과 비교했을 때 SnapCenter 및 SAP HANA Studio에서 백업을 삭제하는 데 지연이 발생합니다. 이러한 불일치를 방지하기 위해 고객은 일정을 하루에 한 번 더 높은 빈도로 변경할 수 있습니다.

참고 또한 리소스의 토폴로지 뷰에서 새로 고침 버튼을 클릭하여 개별 리소스에 대해 정리 작업을 수동으로 트리거할 수도 있습니다.

정리 작업의 스케줄을 조정하는 방법 또는 수동 새로 고침을 트리거하는 방법에 대한 자세한 내용은 섹션을 참조하십시오 "“오프 사이트 백업 스토리지와 백업 동기화 예약 빈도를 변경합니다.”"

SAP HANA 백업 카탈로그 내에서 데이터 백업의 보존 관리

SnapCenter가 백업, 로컬 Snapshot 또는 파일 기반 백업을 삭제하거나 보조 스토리지에서 백업 삭제를 확인한 경우 이 데이터 백업도 SAP HANA 백업 카탈로그에서 삭제됩니다.

SnapCenter는 운영 스토리지에서 로컬 스냅샷 백업에 대한 SAP HANA 카탈로그 항목을 삭제하기 전에 보조 스토리지에 백업이 여전히 존재하는지 확인합니다.

로그 백업의 보존 관리

SAP HANA 데이터베이스는 로그 백업을 자동으로 생성합니다. 이러한 로그 백업을 실행하면 SAP HANA에 구성된 백업 디렉토리에 있는 각 개별 SAP HANA 서비스에 대한 백업 파일이 생성됩니다.

최신 데이터 백업보다 오래된 로그 백업은 더 이상 전달 복구에 필요하지 않으므로 삭제할 수 있습니다.

SnapCenter는 다음 단계를 수행하여 파일 시스템 레벨뿐만 아니라 SAP HANA 백업 카탈로그에서 로그 파일 백업의 하우스키핑을 처리합니다.

  1. SnapCenter는 SAP HANA 백업 카탈로그를 읽어 가장 오래된 파일 기반 또는 스냅샷 백업의 백업 ID를 가져옵니다.

  2. SnapCenter는 SAP HANA 카탈로그에 있는 모든 로그 백업과 이 백업 ID보다 오래된 파일 시스템을 삭제합니다.

참고 SnapCenter는 SnapCenter에서 생성한 백업의 하우스키핑만 처리합니다. SnapCenter 외부에서 추가 파일 기반 백업이 생성되는 경우 파일 기반 백업이 백업 카탈로그에서 삭제되었는지 확인해야 합니다. 이러한 데이터 백업이 백업 카탈로그에서 수동으로 삭제되지 않으면 가장 오래된 데이터 백업이 될 수 있으며, 이 파일 기반 백업이 삭제될 때까지 오래된 로그 백업이 삭제되지 않습니다.
참고 정책 구성에서 필요 시 백업에 대해 보존 정책이 정의되어 있더라도 필요에 따라 다른 백업을 실행할 때만 관리 작업이 수행됩니다. 따라서 일반적으로 SnapCenter에서 필요 시 백업을 수동으로 삭제하여 SAP HANA 백업 카탈로그에서 해당 백업도 삭제되며 로그 백업 정리 정돈이 이전의 주문형 백업을 기반으로 하는지 확인해야 합니다.

로그 백업 보존 관리는 기본적으로 설정됩니다. 필요한 경우 섹션에 설명된 대로 비활성화할 수 있습니다 "“HANA 플러그인 호스트에서 자동 검색을 사용하지 않도록 설정합니다.”"

Snapshot 백업의 용량 요구 사항

기존 데이터베이스의 변경률에 비해 스토리지 계층의 블록 변경률이 더 높아야 합니다. 열 저장소의 HANA 테이블 병합 프로세스로 인해 전체 테이블이 변경된 블록만 아니라 디스크에 기록됩니다.

하루 동안 여러 스냅샷 백업을 수행한 경우 고객 기반의 데이터에 의하면 20%에서 50% 사이의 일일 변경률이 표시됩니다. SnapVault 타겟에서 복제를 하루에 한 번만 수행하면 일일 변경률이 일반적으로 더 작아집니다.

복원 및 복구 작업

SnapCenter를 사용하여 작업을 복원합니다

HANA 데이터베이스 측면에서 SnapCenter는 두 가지 다른 복원 작업을 지원합니다.

  • * 전체 리소스의 복원 * HANA 시스템의 모든 데이터가 복원됩니다. HANA 시스템에 하나 이상의 테넌트가 포함된 경우 시스템 데이터베이스의 데이터와 모든 테넌트의 데이터가 복원됩니다.

  • * 단일 테넌트의 복원. * 선택한 테넌트의 데이터만 복원됩니다.

스토리지의 관점에서 위의 복원 작업은 사용된 스토리지 프로토콜(NFS 또는 Fibre Channel SAN), 구성된 데이터 보호(오프사이트 백업 스토리지를 사용하거나 사용하지 않는 운영 스토리지), 및 복구 작업에 사용할 선택한 백업(운영 또는 오프사이트 백업 스토리지에서 복구)

운영 스토리지에서 전체 리소스 복원

운영 스토리지에서 전체 리소스를 복구할 때 SnapCenter는 두 가지 ONTAP 기능을 지원하여 복구 작업을 실행합니다. 다음 두 기능 중 하나를 선택할 수 있습니다.

  • * 볼륨 기반 SnapRestore. * 볼륨 기반 SnapRestore는 스토리지 볼륨의 콘텐츠를 선택한 스냅샷 백업 상태로 되돌립니다.

    • NFS를 사용하여 자동으로 검색된 리소스에 대해 볼륨 복원 확인란을 사용할 수 있습니다.

    • 수동 구성된 리소스에 대한 Complete Resource 라디오 버튼

  • * 파일 기반 SnapRestore. * 단일 파일 SnapRestore라고도 하는 파일 기반 SnapRestore은 모든 개별 파일(NFS) 또는 모든 LUN(SAN)을 복원합니다.

    • 자동 검색 리소스에 대한 기본 복원 방법입니다. NFS의 볼륨 복원 확인란을 사용하여 변경할 수 있습니다.

    • 수동 구성된 리소스에 대한 파일 레벨 라디오 버튼

다음 표에서는 여러 복원 방법을 비교하여 보여 줍니다.

볼륨 기반 SnapRestore 파일 기반 SnapRestore

복원 작업 속도입니다

볼륨 크기에 관계없이 매우 빠르게 수행할 수 있습니다

매우 빠른 복원 작업이지만 스토리지 시스템에서 백그라운드 복제 작업을 사용하므로 새 스냅샷 백업의 생성이 차단됩니다

스냅샷 백업 기록

이전 스냅샷 백업으로 복원하면 최신 스냅샷 백업이 모두 제거됩니다.

영향 없음

디렉토리 구조 복구

디렉토리 구조도 복구됩니다

NFS: 디렉토리 구조가 아닌 개별 파일만 복구합니다. 디렉토리 구조도 손실된 경우 복구 작업을 실행하기 전에 수동으로 생성해야 합니다. SAN: 디렉토리 구조도 복구됩니다

오프사이트 백업 스토리지로 복제를 통해 구성된 리소스입니다

SnapVault 동기화에 사용된 스냅샷 복사본보다 이전 버전의 스냅샷 복사본 백업에는 볼륨 기반 복원을 수행할 수 없습니다

모든 스냅샷 백업을 선택할 수 있습니다

오프사이트 백업 스토리지에서 전체 리소스 복구

오프사이트 백업 스토리지로부터의 복구는 항상 스냅샷 백업 컨텐츠로 스토리지 볼륨의 모든 파일 또는 모든 LUN을 덮어쓰는 SnapVault 복원 작업을 사용하여 실행됩니다.

단일 테넌트의 복원

단일 테넌트를 복원하려면 파일 기반 복원 작업이 필요합니다. 사용된 스토리지 프로토콜에 따라 SnapCenter에서 다양한 복원 워크플로우를 실행합니다.

  • NFS:

    • 운영 스토리지: 테넌트 데이터베이스의 모든 파일에 대해 파일 기반 SnapRestore 작업이 실행됩니다.

    • 오프사이트 백업 스토리지: 테넌트 데이터베이스의 모든 파일에 대해 SnapVault 복원 작업이 실행됩니다.

  • SAN:

    • 운영 스토리지: LUN을 클론 생성하고 데이터베이스 호스트에 연결하고 테넌트 데이터베이스의 모든 파일을 복사합니다.

    • 오프사이트 백업 스토리지 LUN을 클론 생성하고 데이터베이스 호스트에 연결하고 테넌트 데이터베이스의 모든 파일을 복사합니다.

자동 검색된 HANA 단일 컨테이너 및 MDC 단일 테넌트 시스템의 복원 및 복구

자동 검색된 HANA 단일 컨테이너 및 HANA MDC 단일 테넌트 시스템은 SnapCenter를 통한 자동 복원 및 복구를 지원합니다. 이러한 HANA 시스템의 경우 SnapCenter는 다음 그림과 같이 세 가지 다른 복원 및 복구 워크플로우를 지원합니다.

  • * 수동 복구가 포함된 단일 테넌트 * 단일 테넌트 복원 작업을 선택하면 SnapCenter는 선택한 스냅샷 백업에 포함된 모든 테넌트를 나열합니다. 테넌트 데이터베이스를 수동으로 중지하고 복구해야 합니다. SnapCenter를 사용한 복구 작업은 NFS에 대한 단일 파일 SnapRestore 작업 또는 SAN 환경에 대한 클론, 마운트, 복제 작업을 통해 수행됩니다.

  • * 자동 복구를 통해 리소스를 완료합니다. * 전체 리소스 복원 작업과 자동 복구를 선택하면 SnapCenter를 통해 전체 워크플로우가 자동화됩니다. SnapCenter는 최신 상태, 시점 또는 특정 백업 복구 작업을 지원합니다. 선택한 복구 작업은 시스템 및 테넌트 데이터베이스에 사용됩니다.

  • * 수동 복구를 사용하여 리소스를 완료합니다. * 복구 안 함을 선택하면 SnapCenter에서 HANA 데이터베이스를 중지하고 필요한 파일 시스템(마운트 해제, 마운트) 및 복원 작업을 실행합니다. 시스템 및 테넌트 데이터베이스를 수동으로 복구해야 합니다.

오류: 그래픽 이미지가 없습니다

자동으로 검색된 HANA MDC 다중 테넌트 시스템의 복원 및 복구

여러 테넌트가 포함된 HANA MDC 시스템을 자동으로 검색할 수 있지만 현재 SnapCenter 릴리즈에서는 자동 복원 및 복구가 지원되지 않습니다. 여러 테넌트가 있는 MDC 시스템의 경우 SnapCenter는 다음 그림과 같이 두 가지 다른 복원 및 복구 워크플로우를 지원합니다.

  • 수동 복구가 있는 단일 테넌트

  • 수동 복구를 통해 리소스를 완료합니다

워크플로는 이전 섹션에서 설명한 것과 같습니다.

오류: 그래픽 이미지가 없습니다

수동으로 구성된 HANA 리소스의 복원 및 복구

수동 구성 HANA 리소스는 자동 복원 및 복구에 사용되지 않습니다. 또한 하나 또는 여러 테넌트가 있는 MDC 시스템의 경우 단일 테넌트 복원 작업이 지원되지 않습니다.

수동으로 구성된 HANA 리소스의 경우 다음 그림과 같이 SnapCenter는 수동 복구만 지원합니다. 수동 복구 워크플로는 이전 섹션에서 설명한 것과 동일합니다.

오류: 그래픽 이미지가 없습니다

복원 및 복구 작업을 요약합니다

다음 표에는 SnapCenter의 HANA 리소스 구성에 따라 복구 및 복구 작업이 요약되어 있습니다.

SnapCenter 리소스 구성 복원 및 복구 옵션 HANA 데이터베이스 중지 이전 마운트 해제, 복구 작업 후 마운트 복구 작업

자동 검색된 단일 컨테이너 MDC 단일 테넌트

  • 둘 중 하나를 사용하여 리소스를 완료합니다

  • 기본값(모든 파일)

  • 볼륨 복원(운영 스토리지의 NFS만 해당)

  • 자동 복구가 선택되었습니다

SnapCenter로 자동화되었습니다

SnapCenter로 자동화되었습니다

SnapCenter로 자동화되었습니다

  • 둘 중 하나를 사용하여 리소스를 완료합니다

  • 기본값(모든 파일)

  • 볼륨 복원(운영 스토리지의 NFS만 해당)

  • 선택한 복구가 없습니다

SnapCenter로 자동화되었습니다

SnapCenter로 자동화되었습니다

수동

  • 테넌트 복원

수동

필요하지 않습니다

수동

MDC 다중 테넌트가 자동으로 검색되었습니다

  • 둘 중 하나를 사용하여 리소스를 완료합니다

  • 기본값(모든 파일)

  • 볼륨 복원(운영 스토리지의 NFS만 해당)

  • 자동 복구는 지원되지 않습니다

SnapCenter로 자동화되었습니다

SnapCenter로 자동화되었습니다

수동

  • 테넌트 복원

수동

필요하지 않습니다

수동

모든 수동 구성 리소스

  • 완벽한 리소스(=볼륨 복원, 운영 스토리지의 NFS 및 SAN에만 사용 가능)

  • 파일 레벨(모든 파일)

  • 자동 복구는 지원되지 않습니다

수동

수동

수동