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

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

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

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

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

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

다음 그림에서는 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를 사용하여 고가용성을 달성할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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