SnapCenter 데이터 보호 개념과 모범 사례에 대해 알아보세요.
변경 제안
PDF
SAP HANA 환경을 위한 SnapCenter 배포 옵션, 데이터 보호 전략 및 백업 보존 관리에 대해 알아보세요. SnapCenter 데이터베이스 호스트나 중앙 호스트에 플러그인 배포, 자동 검색 및 수동 구성, 파일 기반 백업이나 hdbpersdiag를 사용한 블록 일관성 검사, 기본 및 보조 스토리지 전반에 걸친 포괄적인 보존 관리를 지원합니다.
SAP HANA용 SnapCenter 플러그인 배포 옵션
다음 그림은 SnapCenter 서버, SAP HANA 데이터베이스 및 스토리지 시스템 간 통신의 논리적 보기를 보여줍니다. SnapCenter 서버는 HANA 및 Linux 플러그인을 활용하여 HANA 데이터베이스와 Linux 운영 체제와 통신합니다.
SnapCenter 플러그인에 권장되고 기본으로 제공되는 배포 옵션은 HANA 데이터베이스 호스트에 설치하는 것입니다. 이 배포 옵션을 사용하면 SnapCenter 지원 구성 장에서 설명한 모든 구성과 기능이 유효합니다. SnapCenter 플러그인을 HANA 데이터베이스 호스트에 설치할 수 없고 SnapCenter 서버 자체일 수 있는 중앙 플러그인 호스트에서 구성해야 하는 몇 가지 예외가 있습니다. HANA 다중 호스트 시스템이나 IBM Power 플랫폼에서 실행되는 HANA 시스템에는 중앙 플러그인 호스트가 필요합니다. 두 가지 배포 옵션을 혼합하여 사용할 수도 있습니다. 예를 들어 SnapCenter 서버를 다중 호스트 시스템의 중앙 플러그인 호스트로 사용하고 다른 모든 단일 호스트 HANA 시스템의 경우 HANA 데이터베이스 호스트에 플러그인을 배포할 수 있습니다.
SnapCenter 에서는 HANA 리소스를 자동으로 검색하거나 수동으로 구성할 수 있습니다. HANA 및 Linux 플러그인이 데이터베이스 호스트에 배포되면 기본적으로 HANA 시스템이 자동으로 검색됩니다. SnapCenter 자동 검색은 동일한 호스트에서 여러 HANA 설치를 지원하지 않습니다. 중앙 플러그인 호스트를 사용하여 관리되는 HANA 시스템은 SnapCenter 에서 수동으로 구성해야 합니다. 또한, 비데이터 볼륨은 기본적으로 수동으로 구성된 리소스입니다.
| 플러그인이 배포됨 | SnapCenter 리소스 | |
|---|---|---|
HANA 데이터베이스 |
데이터베이스 호스트 |
자동 발견됨 |
HANA 데이터베이스 |
중앙 플러그인 호스트 |
수동 구성됨 |
비데이터 볼륨 |
해당 없음 |
수동 구성됨 |
SnapCenter HANA 시스템을 위한 중앙 플러그인 배포를 지원하지만 플랫폼 및 기능 지원에는 제한이 있습니다. 다음 인프라 구성 및 작업은 중앙 플러그인 호스트로 구성된 HANA 시스템에서 지원되지 않습니다.
-
FC 데이터 저장소를 사용한 VMware
-
SnapMirror 액티브 싱크
-
중앙 플러그인 호스트로 사용하는 경우 SnapCenter 서버 고가용성
-
HANA 시스템 자동 검색
-
자동화된 HANA 데이터베이스 복구
-
자동화된 SAP 시스템 새로 고침
-
단일 테넌트 복원
SAP HANA 데이터베이스 호스트에 배포된 HANA용 SnapCenter 플러그인
SnapCenter 서버는 HANA 플러그인을 통해 HANA 데이터베이스와 통신합니다. HANA 플러그인은 HANA hdbsql 클라이언트 소프트웨어를 사용하여 HANA 데이터베이스에 SQL 명령을 실행합니다. HANA hdb 사용자 저장소는 HANA 데이터베이스에 액세스하기 위한 사용자 자격 증명, 호스트 이름 및 포트 정보를 제공하는 데 사용됩니다. SnapCenter Linux 플러그인은 호스트 파일 시스템 작업과 파일 시스템 및 스토리지 리소스의 자동 검색을 처리하는 데 사용됩니다.
HANA 플러그인이 HANA 데이터베이스 호스트에 배포되면 HANA 시스템은 SnapCenter 에서 자동으로 검색되고 SnapCenter 에서 자동 검색된 리소스로 플래그가 지정됩니다.
SnapCenter 서버 고가용성
SnapCenter 2노드 HA 구성으로 설정할 수 있습니다. 이러한 구성에서는 로드 밸런서(예: F5)를 사용하여 SnapCenter 호스트에 액세스합니다. SnapCenter 저장소(MySQL 데이터베이스)는 SnapCenter 에 의해 두 호스트 간에 복제되므로 SnapCenter 데이터는 항상 동기화됩니다.
HANA 플러그인이 SnapCenter 서버에 설치된 경우 SnapCenter 서버 HA는 지원되지 않습니다. SnapCenter HA에 대한 자세한 내용은 다음에서 확인할 수 있습니다. "고가용성을 위한 SnapCenter 서버 구성".
중앙 플러그인 호스트
이전 장에서 논의한 대로 중앙 플러그인이 필요합니다.
-
HANA 다중 호스트 시스템
-
IBM Power에서 실행되는 HANA 시스템
중앙 플러그인 호스트를 사용하는 경우 HANA 플러그인과 SAP HANA hdbsql 클라이언트를 HANA 데이터베이스 호스트 외부의 호스트에 설치해야 합니다. 이 호스트는 SnapCenter 서버 등 Windows 또는 Linux 호스트가 될 수 있습니다.
|
Windows에서 SnapCenter 서버를 실행하면 Windows 시스템을 중앙 플러그인 호스트로 사용할 수 있습니다. Linux에서 SnapCenter 서버를 실행하는 경우 다른 호스트를 중앙 플러그인 호스트로 사용해야 합니다. |
HANA 다중 호스트 시스템의 경우 모든 작업자 및 대기 호스트에 대한 SAP HANA 사용자 저장소 키는 중앙 플러그인 호스트에서 구성해야 합니다. SnapCenter 제공된 각 키를 사용하여 데이터베이스에 연결을 시도하므로 시스템 데이터베이스(HANA 네임 서버)가 다른 호스트로 장애 조치되는 것과 관계없이 독립적으로 작동할 수 있습니다.
중앙 플러그인 호스트에서 관리하는 여러 개의 단일 호스트 HANA 시스템의 경우, HANA 시스템의 모든 개별 SAP HANA 사용자 저장소 키는 중앙 플러그인 호스트에서 구성되어야 합니다.
SAP HANA 블록 일관성 검사
SAP에서는 전반적인 백업 전략에 정기적인 HANA 블록 일관성 검사를 포함할 것을 권장합니다. 기존의 파일 기반 백업에서는 이러한 확인 작업이 각 백업 작업마다 수행됩니다. 스냅샷 백업의 경우 스냅샷 백업 작업 외에도 일관성 검사를 실행해야 합니다(예: 주 1회).
기술적으로 블록 일관성 검사를 실행하는 데는 두 가지 옵션이 있습니다.
-
표준 파일 기반 또는 backint 기반 백업 실행
-
HANA 도구 hdbpersdiag 실행, 또한 참조하세요. "지속성 일관성 검사 | SAP 도움말 포털"
HANA hdbpersdiag 도구는 HANA 설치의 일부이며, 오프라인 HANA 데이터베이스에 대해 블록 일관성 검사 작업을 실행할 수 있습니다. 따라서 기존 스냅샷 백업을 hdbpersdiag에 제시할 수 있는 스냅샷 백업과 함께 사용하기에 완벽하게 적합합니다.
두 가지 접근 방식을 비교해보면, hdbpersdiag는 HANA 블록 일관성 검사를 위한 파일 기반 백업에 비해 상당한 이점을 가지고 있습니다. 한 가지 차원은 필요한 저장 용량입니다. 파일 기반 백업의 경우 각 HANA 시스템에서 최소한 하나의 백업 크기만큼의 백업을 사용할 수 있어야 합니다. 예를 들어, 지속성 크기가 3TB인 HANA 시스템이 15개 있다면 일관성 검사에만 45TB가 추가로 필요합니다. hdbpersdiag를 사용하면 기존 스냅샷 백업이나 기존 스냅샷 백업의 FlexClone 대상으로 작업이 실행되므로 추가 저장 용량이 필요하지 않습니다. 두 번째 차원은 일관성 검사 작업 중 HANA 호스트의 CPU 부하입니다. 파일 기반 백업에는 HANA 데이터베이스 호스트에서 CPU 사이클이 필요하지만, hdbpersdiag 처리는 중앙 검증 호스트와 함께 사용하면 HANA 호스트에서 완전히 오프로드될 수 있습니다. 아래 표는 주요 특징을 요약한 것입니다.
| 필요한 저장 용량 | HANA 호스트의 CPU 및 네트워크 부하 | |
|---|---|---|
파일 기반 백업 |
각 HANA 시스템에 대한 최소 1 x 데이터 백업 크기 |
높은 |
HANA 호스트의 스냅샷 디렉토리를 사용하는 hdbpersdiag(NFS 전용) |
None |
중간 |
FlexClone 볼륨으로 hdbpersdiag를 실행하는 데 사용되는 중앙 검증 호스트 |
None |
None |
NetApp HANA 블록 일관성 검사를 실행하기 위해 hdbpersdiag를 사용할 것을 권장합니다. 구현에 대한 자세한 내용은 다음 장에서 확인할 수 있습니다. "SnapCenter 사용한 블록 일관성 검사".
데이터 보호 전략
SnapCenter 및 SAP HANA 플러그인을 구성하기 전에 다양한 SAP 시스템의 RTO 및 RPO 요구사항을 기준으로 데이터 보호 전략을 정의해야 합니다.
일반적인 접근 방식은 운영, 개발, 테스트 또는 샌드박스 시스템과 같은 시스템 유형을 정의하는 것입니다. 동일한 시스템 유형의 모든 SAP 시스템은 일반적으로 동일한 데이터 보호 매개 변수를 사용합니다.
정의해야 하는 매개 변수는 다음과 같습니다.
-
Snapshot 백업을 얼마나 자주 실행해야 합니까?
-
Snapshot 복사본 백업을 기본 스토리지 시스템에 얼마나 오래 보관해야 합니까?
-
블록 무결성 검사를 얼마나 자주 실행해야 합니까?
-
1차 백업을 2차 백업 사이트로 복제해야 합니까?
-
백업은 보조 백업 저장소에 얼마 동안 보관해야 합니까?
다음 표는 생산, 개발, 테스트 시스템 유형에 대한 데이터 보호 매개변수의 예를 보여줍니다. 운영 시스템의 경우 높은 백업 빈도가 정의되었으며, 백업은 하루에 한 번씩 보조 백업 사이트에 복제됩니다. 테스트 시스템은 요구 사항이 낮고 백업 복제가 없습니다.
| 매개 변수 | 운영 시스템 | 개발 시스템 | 시스템을 테스트합니다 |
|---|---|---|---|
백업 빈도 |
6시간마다 |
6시간마다 |
12시간마다 |
기본 보존 |
3일 |
3일 |
6일 |
블록 무결성 검사 |
일주일에 한 번 |
일주일에 한 번 |
아니요 |
보조 백업 사이트로 복제 |
하루에 한 번 |
하루에 한 번 |
아니요 |
2차 백업 보존 |
2주 |
2주 |
아니요 |
다음 표는 위의 데이터 보호 매개변수에 대해 구성해야 할 정책과 일정을 보여줍니다.
| 정책 | 백업 유형 | 일정 빈도 | 기본 보존 | SnapVault 복제 | 2차 보존 |
|---|---|---|---|---|---|
로컬스냅 |
스냅샷 기반 |
6시간마다 |
개수=12 |
아니요 |
해당 없음 |
로컬스냅앤스냅볼트 |
스냅샷 기반 |
하루에 한 번 |
개수=2 |
예 |
개수=14 |
스냅앤콜HDB퍼스디아그 |
스냅샷 기반 |
일주일에 한 번 |
개수=2 |
아니요 |
해당 없음 |
|
|
ONTAP 시스템 또는 FSx for ONTAP 의 경우 SnapCenter 에서 SnapVault 업데이트 작업을 실행하기 전에 SnapVault 복제를 위해 ONTAP 에서 데이터 보호 관계를 구성해야 합니다. 2차 보존은 ONTAP 보호 정책에 정의되어 있습니다. |
|
|
ANF 백업의 경우 SnapCenter 외부에서 추가 구성이 필요하지 않습니다. ANF 백업 보조 보존은 SnapCenter 에서 관리합니다. |
|
|
이 예제 구성에서는 블록 무결성 검사 작업에 hdbpersdiag가 사용됩니다. 자세한 내용은 장에서 확인할 수 있습니다. "SnapCenter 사용한 블록 일관성 검사". |
아래 그림은 일정과 백업 보존 기간을 요약한 것입니다. SnapCenter 사용하여 로그 백업 보존을 관리하는 경우 가장 오래된 스냅샷 백업보다 오래된 모든 로그 백업이 삭제됩니다. 다시 말해, 로그 백업은 사용 가능한 모든 백업을 현재 시점으로 복구하는 데 필요한 기간 동안 보관됩니다.
암호화 루트 키 백업
HANA 지속성 암호화를 사용하는 경우 표준 데이터 백업 외에도 루트 키의 백업을 만드는 것이 중요합니다. 데이터 볼륨과 HANA 설치 파일 시스템이 손실된 경우 HANA 데이터베이스를 복구하려면 루트 키 백업이 필요합니다. 자세한 내용은 다음을 참조하세요. "SAP HANA 관리 가이드".
|
|
루트 키가 변경되면 새로운 루트 키를 사용하여 이전에 생성된 이전 HANA 데이터베이스 백업을 복구할 수 없다는 점을 명심하세요. 백업을 생성할 당시 활성화되어 있던 루트 키가 항상 필요합니다. |
백업 작업
SnapCenter 단일 또는 여러 테넌트가 있는 HANA MDC 시스템의 스냅샷 백업 작업을 지원합니다. SnapCenter HANA MDC 시스템의 두 가지 다른 복원 작업도 지원합니다. 전체 시스템, 시스템 DB 및 모든 테넌트를 복원할 수도 있고, 하나의 테넌트만 복원할 수도 있습니다. SnapCenter 이러한 작업을 실행하려면 몇 가지 전제 조건이 있습니다.
MDC 시스템에서는 테넌트 구성이 반드시 정적이지는 않습니다. 세입자를 추가하거나 삭제할 수 있습니다. SnapCenter HANA 데이터베이스가 SnapCenter 에 추가될 때 발견된 구성에 의존할 수 없습니다. 단일 테넌트 복원 작업을 활성화하려면 SnapCenter 각 스냅샷 백업에 포함된 테넌트를 알아야 합니다. 또한 스냅샷 백업에 포함된 각 테넌트에 속하는 파일과 디렉토리를 알아야 합니다.
따라서 SnapCenter 각 백업 작업을 통해 테넌트 정보를 식별합니다. 여기에는 테넌트 이름과 해당 파일 및 디렉토리 정보가 포함됩니다. 단일 테넌트 복원 작업을 지원하려면 이 데이터를 스냅샷 백업 메타데이터에 저장해야 합니다.
애플리케이션 자동 검색의 또 다른 단계는 HANA 시스템 복제(HSR) 기본 또는 보조 노드를 감지하는 것입니다. HANA 시스템이 HSR로 구성된 경우 SnapCenter 각 백업 작업에서 기본 노드를 식별하여 백업 SQL 명령이 HSR 기본 노드에서 실행되도록 해야 합니다. 또한 참조하세요 "SAP HANA 시스템 복제 - SnapCenter를 사용한 백업 및 복구".
SnapCenter 또한 HANA 데이터 볼륨 구성을 감지하고 이를 파일 시스템 및 스토리지 리소스에 매핑합니다. 이러한 접근 방식을 통해 SnapCenter HANA 볼륨 구성 변경(예: 여러 파티션 또는 볼륨 마이그레이션과 같은 스토리지 구성 변경)을 처리할 수 있습니다.
다음 단계는 스냅샷 백업 작업 자체입니다. 이 단계에는 HANA 데이터베이스 스냅샷을 트리거하는 SQL 명령, 스토리지 스냅샷 백업, HANA 스냅샷 작업을 닫는 SQL 명령이 포함됩니다. close 명령을 사용하면 HANA 데이터베이스는 시스템 DB와 각 테넌트의 백업 카탈로그를 업데이트합니다.
|
|
하나 이상의 테넌트가 중지된 경우 SAP는 MDC 시스템에 대한 스냅샷 백업 작업을 지원하지 않습니다. |
데이터 백업 및 HANA 백업 카탈로그 관리의 보존 관리를 위해 SnapCenter는 첫 번째 단계에서 식별된 시스템 데이터베이스 및 모든 테넌트 데이터베이스에 대해 카탈로그 삭제 작업을 실행해야 합니다. 로그 백업과 마찬가지로 SnapCenter 워크플로도 백업 작업의 일부인 각 테넌트에서 작동해야 합니다.
다음 그림에서는 백업 워크플로우의 개요를 보여 줍니다.
백업 보존 관리
데이터 백업 보존 관리 및 로그 백업 정리정돈 은 보존 관리를 포함하여 5가지 주요 영역으로 나눌 수 있습니다.
-
운영 스토리지의 로컬 백업
-
파일 기반 백업
-
보조 저장소에서의 백업(SnapVault 또는 ANF 백업)
-
SAP HANA 백업 카탈로그 내의 데이터 백업
-
SAP HANA 백업 카탈로그 및 파일 시스템의 로그 백업
다음 그림에서는 다양한 워크플로우와 각 작업의 종속 관계를 간략하게 보여 줍니다. 다음 섹션에서는 다양한 작업에 대해 자세히 설명합니다.
운영 스토리지에서 로컬 백업의 보존 관리
SnapCenter SnapCenter 백업 정책에 정의된 보존 기간에 따라 기본 스토리지와 SnapCenter 저장소에서 스냅샷 복사본을 삭제하여 SAP HANA 데이터베이스 백업과 비데이터 볼륨 백업의 정리 작업을 처리합니다. SnapCenter 의 각 백업 워크플로에는 보존 관리가 포함되어 있습니다. 기본 저장소의 로컬 백업도 SnapCenter 에서 수동으로 삭제할 수 있습니다.
파일 기반 백업의 보존 관리
SnapCenter SnapCenter 백업 정책에 정의된 보존 기간에 따라 파일 시스템의 백업을 삭제하여 파일 기반 백업의 정리 작업을 처리합니다. SnapCenter 의 각 백업 워크플로우에서는 보존 관리 로직이 실행됩니다.
보조 저장소(SnapVault)에서의 백업 보존 관리
보조 저장소(SnapVault)에서 백업의 보존 관리를 담당하는 ONTAP 은 ONTAP 보호 관계에 정의된 보존을 기반으로 관리합니다. SnapCenter 저장소의 보조 저장소에서 이러한 변경 사항을 동기화하기 위해 SnapCenter 예약된 정리 작업을 사용합니다. 이 정리 작업은 모든 SnapCenter 플러그인과 모든 리소스에 대한 모든 보조 저장소 백업을 SnapCenter 저장소와 동기화합니다.
정리 작업은 기본적으로 일주일에 한 번씩 예약됩니다. 이 주간 일정을 적용하면 SnapCenter 와 SAP HANA Studio에서 백업을 삭제하는 데 시간이 걸리는데, 이는 보조 저장소에서 이미 삭제된 백업과 비교했을 때 지연이 발생합니다. 이러한 불일치를 피하기 위해 고객은 일정을 더 자주(예: 하루에 한 번) 변경할 수 있습니다. 정리 작업 일정을 조정하는 방법이나 수동 새로 고침을 트리거하는 방법에 대한 자세한 내용은 다음 장을 참조하십시오. "2차 백업 정리".
2차 저장소(ANF 백업)에서의 백업 보존 관리
ANF 백업의 보존은 SnapCenter 에서 구성하고 처리합니다. SnapCenter SnapCenter 백업 정책에 정의된 보존 기간에 따라 백업을 삭제하여 ANF 백업의 정리 작업을 처리합니다. SnapCenter 의 각 백업 워크플로에는 보존 관리가 포함되어 있습니다.
SAP HANA 백업 카탈로그 내에서 데이터 백업의 보존 관리
SnapCenter 백업, 로컬 스냅샷 또는 파일 기반을 삭제하거나 SnapCenter 보조 저장소에서 백업 삭제를 식별한 경우, 이 데이터 백업은 SAP HANA 백업 카탈로그에서도 삭제됩니다. SnapCenter 기본 저장소에서 로컬 스냅샷 백업에 대한 SAP HANA 카탈로그 항목을 삭제하기 전에 백업이 보조 저장소에 여전히 있는지 확인합니다.
로그 백업의 보존 관리
SAP HANA 데이터베이스는 자동으로 로그 백업을 생성합니다. 이러한 작업은 SAP HANA에 구성된 백업 디렉토리에 각 SAP HANA 서비스에 대한 백업 파일을 생성합니다. 최신 데이터 백업보다 오래된 로그 백업은 더 이상 전방 복구에 필요하지 않으므로 삭제할 수 있습니다. SnapCenter 다음 단계를 실행하여 파일 시스템 수준과 SAP HANA 백업 카탈로그에서 로그 파일 백업의 정리 작업을 처리합니다.
-
SnapCenter SAP HANA 백업 카탈로그를 읽어 가장 오래된 성공적인 데이터 백업의 백업 ID를 가져옵니다.
-
SnapCenter는 SAP HANA 카탈로그에 있는 모든 로그 백업과 이 백업 ID보다 오래된 파일 시스템을 삭제합니다.
|
|
SnapCenter는 SnapCenter에서 생성한 백업의 하우스키핑만 처리합니다. SnapCenter 외부에서 추가 파일 기반 백업이 생성되는 경우 파일 기반 백업이 백업 카탈로그에서 삭제되었는지 확인해야 합니다. 이러한 데이터 백업이 백업 카탈로그에서 수동으로 삭제되지 않으면 가장 오래된 데이터 백업이 될 수 있으며, 이 파일 기반 백업이 삭제될 때까지 오래된 로그 백업이 삭제되지 않습니다. |
|
|
정책 구성에서 주문형 백업에 대한 보존 기간이 정의되어 있더라도, 다른 주문형 백업이 실행될 때만 정리 작업이 수행됩니다. 따라서 주문형 백업은 일반적으로 SnapCenter 에서 수동으로 삭제하여 이러한 백업이 SAP HANA 백업 카탈로그에서도 삭제되고 로그 백업 정리가 이전 주문형 백업을 기반으로 하지 않도록 해야 합니다. |
|
|
로그 백업 보존 관리는 기본적으로 활성화되어 있습니다. 필요한 경우 자동 로그 백업 정리 비활성화 섹션에 설명된 대로 비활성화할 수 있습니다. |