단일 리소스를 사용하는 SnapCenter 구성
SnapCenter 리소스는 HANA 시스템 복제 환경의 가상 IP 주소(호스트 이름)로 구성됩니다. 이 접근 방식을 통해 SnapCenter는 호스트 1과 호스트 2가 운영 호스트인지에 관계없이 항상 운영 호스트와 통신합니다. 두 SAP HANA 호스트의 데이터 볼륨은 SnapCenter 리소스에 포함되어 있습니다.
가상 IP 주소가 항상 기본 SAP HANA 호스트에 바인딩되어 있다고 가정합니다. 가상 IP 주소의 페일오버는 SnapCenter 외부에서 HANA 시스템 복제 페일오버 워크플로우의 일부로 수행됩니다. |
호스트 1을 운영 호스트로 사용하여 백업을 실행하면 호스트 1의 데이터 볼륨에서 데이터베이스 정합성 보장 스냅샷 백업이 생성됩니다. 호스트 2의 데이터 볼륨은 SnapCenter 리소스에 포함되므로 이 볼륨에 대해 또 다른 스냅샷 복사본이 생성됩니다. 이 스냅샷 복사본은 데이터베이스 정합성이 보장되지 않고 2차 호스트의 장애 이미지일 뿐입니다.
SAP HANA 백업 카탈로그와 SnapCenter 리소스에는 호스트 1에서 생성된 백업이 포함되어 있습니다.
다음 그림에서는 호스트 2로 페일오버 후 백업 작업과 호스트 2에서 호스트 1로 복제를 보여 줍니다. SnapCenter는 SnapCenter 리소스에 구성된 가상 IP 주소를 사용하여 호스트 2와 자동으로 통신합니다. 이제 호스트 2에서 백업이 생성됩니다. SnapCenter은 2개의 스냅샷 복사본을 생성합니다. 하나는 호스트 2의 데이터 볼륨에 대한 데이터베이스 정합성 보장 백업이고 다른 하나는 호스트 1의 데이터 볼륨에 있는 스냅샷 복사본입니다. 이제 SAP HANA 백업 카탈로그와 SnapCenter 리소스에 호스트 1에서 생성된 백업과 호스트 2에서 생성된 백업이 포함됩니다.
데이터 및 로그 백업의 하우스키핑은 정의된 SnapCenter 보존 정책을 기반으로 하며, 운영 또는 보조 호스트와 상관없이 백업이 삭제됩니다.
섹션에 설명된 대로 "스토리지 스냅샷 백업 및 SAP 시스템 복제"스토리지 기반 Snapshot 백업을 사용한 복구 작업은 복원해야 하는 백업에 따라 다릅니다. 로컬 스토리지 볼륨에서 복구를 수행할 수 있는지 또는 다른 호스트의 스토리지 볼륨에서 복구를 수행해야 하는지 여부를 확인하려면 에서 백업이 생성된 호스트를 확인해야 합니다.
단일 리소스 SnapCenter 구성을 사용하는 경우 SnapCenter는 백업이 생성된 위치를 알지 못합니다. 따라서 SnapCenter 백업 워크플로우에 사전 백업 스크립트를 추가하여 현재 기본 SAP HANA 호스트인 호스트를 식별하는 것이 좋습니다.
다음 그림에서는 백업 호스트의 ID를 보여 줍니다.
SnapCenter 구성
다음 그림은 랩 설정과 필요한 SnapCenter 구성의 개요를 보여 줍니다.
어떤 SAP HANA 호스트가 기본이고 하나의 호스트가 다운된 경우에도 백업 작업을 수행하려면 SnapCenter SAP HANA 플러그인을 중앙 플러그인 호스트에 구축해야 합니다. 연구소 설정에서 SnapCenter 서버를 중앙 플러그인 호스트로 사용했고 SnapCenter 서버에 SAP HANA 플러그인을 배포했습니다.
백업 작업을 수행하기 위해 HANA 데이터베이스에서 사용자가 생성되었습니다. SAP HANA 플러그인이 설치된 SnapCenter 서버에서 사용자 저장소 키를 구성했습니다. 사용자 저장소 키에는 SAP HANA 시스템 복제 호스트('SR-VIP')의 가상 IP 주소가 포함됩니다.
hdbuserstore.exe -u SYSTEM set SSRKEY ssr-vip:31013 SNAPCENTER <password>
SAP HANA 플러그인 배포 옵션 및 사용자 저장소 구성에 대한 자세한 내용은 기술 보고서 TR-4614: "SnapCenter를 사용한 SAP HANA 백업 및 복구"
SnapCenter에서는 이전에 구성한 사용자 저장소 키와 SnapCenter 서버를 "hdbsql" 통신 호스트로 사용하여 다음 그림과 같이 자원을 구성합니다.
다음 그림에서 볼 수 있듯이, 두 SAP HANA 호스트의 데이터 볼륨은 스토리지 설치 공간 구성에 포함됩니다.
앞에서 설명한 것처럼 SnapCenter는 백업이 생성된 위치를 알지 못합니다. 따라서 SnapCenter 백업 워크플로우에 사전 백업 스크립트를 추가하여 현재 기본 SAP HANA 호스트인 호스트를 식별하는 것이 좋습니다. 다음 그림과 같이 백업 워크플로우에 추가된 SQL 문을 사용하여 이 ID를 수행할 수 있습니다.
Select host from “SYS”.M_DATABASE
SnapCenter 백업 작업
이제 백업 작업이 평소와 같이 실행됩니다. 데이터 및 로그 백업의 하우스키핑은 어떤 SAP HANA 호스트가 기본 또는 보조 호스트인지 독립적으로 수행됩니다.
백업 작업 로그에는 SQL 문의 출력이 포함되어 있으므로 백업을 생성한 SAP HANA 호스트를 확인할 수 있습니다.
다음 그림에서는 호스트 1이 운영 호스트로 포함된 백업 작업 로그를 보여 줍니다.
이 그림에서는 호스트 2가 운영 호스트로 포함된 백업 작업 로그를 보여 줍니다.
다음 그림에서는 SAP HANA Studio의 SAP HANA 백업 카탈로그를 보여 줍니다. SAP HANA 데이터베이스가 온라인 상태일 때 SAP HANA Studio에서 백업이 생성된 SAP HANA 호스트가 표시됩니다.
복구 및 복구 작업 중에 사용되는 파일 시스템의 SAP HANA 백업 카탈로그에는 백업을 생성한 호스트 이름이 포함되지 않습니다. 데이터베이스가 다운되었을 때 호스트를 식별하는 유일한 방법은 백업 카탈로그 항목을 두 SAP HANA 호스트의 'backup.log' 파일과 결합하는 것입니다. |
복원 및 복구
앞에서 설명한 대로 선택한 백업이 생성된 위치를 확인하여 필요한 복원 작업을 정의할 수 있어야 합니다. SAP HANA 데이터베이스가 아직 온라인 상태인 경우 SAP HANA Studio를 사용하여 백업이 생성된 호스트를 확인할 수 있습니다. 데이터베이스가 오프라인 상태인 경우 이 정보는 SnapCenter 백업 작업 로그에서만 사용할 수 있습니다.
다음 그림에서는 선택한 백업에 따라 다른 복원 작업을 보여 줍니다.
복구 작업이 타임 스탬프 T3 이후에 수행되어야 하고 호스트 1이 기본 복구 작업인 경우 SnapCenter를 사용하여 T1 또는 T3에서 생성된 백업을 복원할 수 있습니다. 이러한 스냅샷 백업은 호스트 1에 연결된 스토리지 볼륨에서 사용할 수 있습니다.
호스트 2의 스토리지 볼륨에 있는 스냅샷 복사본인 호스트 2(T2)에서 생성된 백업을 사용하여 복구해야 하는 경우 호스트 1에서 백업을 사용할 수 있도록 해야 합니다. 백업에서 NetApp FlexClone 복사본을 생성하고 FlexClone 복사본을 호스트 1에 마운트한 다음 데이터를 원래 위치에 복사하여 이 백업을 사용할 수 있습니다.
단일 SnapCenter 리소스 구성을 사용하면 두 SAP HANA 시스템 복제 호스트의 두 스토리지 볼륨에서 스냅샷 복사본이 생성됩니다. 기본 SAP HANA 호스트의 스토리지 볼륨에서 생성되는 스냅샷 백업만 향후 복구에 사용할 수 있습니다. 2차 SAP HANA 호스트의 스토리지 볼륨에서 생성된 스냅샷 복사본은 향후 복구에 사용할 수 없는 충돌 이미지입니다.
SnapCenter를 사용한 복구 작업은 다음 두 가지 방법으로 수행할 수 있습니다.
-
유효한 백업만 복원합니다
-
유효한 백업 및 충돌 요소를 포함하여 전체 리소스를 복원합니다.다음 섹션에서는 두 가지 다른 복원 작업에 대해 자세히 설명합니다.
다른 호스트에서 생성된 백업의 복구 작업은 섹션에 설명되어 있습니다 "다른 호스트에서 생성된 백업에서 복구 및 복구".
다음 그림에서는 단일 SnapCenter 리소스 구성을 사용하는 복구 작업을 보여 줍니다.
유효한 백업의 SnapCenter 복구만 가능합니다
다음 그림에서는 이 섹션에서 설명하는 복원 및 복구 시나리오의 개요를 보여 줍니다.
호스트 1의 T1에서 백업이 생성되었습니다. 호스트 2에 대한 페일오버가 수행되었습니다. 특정 시점 이후에 호스트 1에 대한 또 다른 페일오버가 수행되었습니다. 현재 시점에서 호스트 1은 운영 호스트입니다.
-
오류가 발생하여 호스트 1에서 T1에 생성된 백업으로 복구해야 합니다.
-
보조 호스트(호스트 2)가 종료되었지만 복원 작업이 실행되지 않습니다.
-
호스트 1의 스토리지 볼륨은 T1에서 생성된 백업으로 복구됩니다.
-
정방향 복구는 호스트 1과 호스트 2의 로그를 사용하여 수행됩니다.
-
호스트 2가 시작되고 호스트 2의 시스템 복제 재동기화가 자동으로 시작됩니다.
다음 그림에서는 SAP HANA Studio의 SAP HANA 백업 카탈로그를 보여 줍니다. 강조 표시된 백업에는 호스트 1에서 T1에서 생성된 백업이 표시됩니다.
복구 및 복구 작업은 SAP HANA Studio에서 시작됩니다. 다음 그림에서 볼 수 있듯이, 백업이 생성된 호스트의 이름이 복구 및 복구 워크플로우에서 표시되지 않습니다.
이 테스트 시나리오에서는 데이터베이스가 아직 온라인 상태일 때 SAP HANA Studio에서 올바른 백업(호스트 1에서 생성된 백업)을 식별할 수 있었습니다. 데이터베이스를 사용할 수 없는 경우 SnapCenter 백업 작업 로그를 확인하여 올바른 백업을 식별해야 합니다. |
SnapCenter에서 백업이 선택되고 파일 레벨 복구 작업이 수행됩니다. 파일 레벨 복구 화면에서는 유효한 백업만 복구되도록 호스트 1 볼륨만 선택됩니다.
복구 작업 후 SAP HANA Studio에서 백업이 녹색으로 강조 표시됩니다. 호스트 1과 호스트 2의 로그 백업의 파일 경로가 백업 카탈로그에 포함되므로 추가 로그 백업 위치를 입력할 필요가 없습니다.
정방향 복구가 완료되면 보조 호스트(호스트 2)가 시작되고 SAP HANA 시스템 복제 재동기화가 시작됩니다.
보조 호스트가 최신 상태이지만(호스트 2에 대해 복원 작업이 수행되지 않음) SAP HANA는 모든 데이터의 전체 복제를 실행합니다. 이 동작은 SAP HANA 시스템 복제를 사용한 복원 및 복구 작업 후 표준 동작입니다. |
유효한 백업 및 충돌 이미지의 SnapCenter 복원
다음 그림에서는 이 섹션에서 설명하는 복원 및 복구 시나리오의 개요를 보여 줍니다.
호스트 1의 T1에서 백업이 생성되었습니다. 호스트 2에 대한 페일오버가 수행되었습니다. 특정 시점 이후에 호스트 1에 대한 또 다른 페일오버가 수행되었습니다. 현재 시점에서 호스트 1은 운영 호스트입니다.
-
오류가 발생하여 호스트 1에서 T1에 생성된 백업으로 복구해야 합니다.
-
2차 호스트(호스트 2)가 종료되고 T1 충돌 이미지가 복구됩니다.
-
호스트 1의 스토리지 볼륨은 T1에서 생성된 백업으로 복구됩니다.
-
정방향 복구는 호스트 1과 호스트 2의 로그를 사용하여 수행됩니다.
-
호스트 2가 시작되고 호스트 2의 시스템 복제 재동기화가 자동으로 시작됩니다.
SAP HANA Studio를 사용한 복구 작업은 섹션에 설명된 단계와 동일합니다 "유효한 백업의 SnapCenter 복구만 가능합니다".
복원 작업을 수행하려면 SnapCenter에서 전체 리소스 를 선택합니다. 두 호스트의 볼륨이 복구됩니다.
정방향 복구가 완료되면 보조 호스트(호스트 2)가 시작되고 SAP HANA 시스템 복제 재동기화가 시작됩니다. 모든 데이터의 전체 복제가 실행됩니다.