모범 사례
ONTAP용 Amazon FSx를 사용한 백업 및 복구
변경 제안
PDF
NetApp Snapshot 기술을 사용하여 몇 분 내에 데이터베이스 백업을 생성할 수 있습니다.
스냅샷 복사본은 스토리지 플랫폼에서 물리적 데이터 블록을 이동하지 않으므로 스냅샷 복사본을 만드는 데 필요한 시간은 데이터베이스의 크기와 상관없습니다. 또한 스냅샷 기술을 사용해도 라이브 SAP 시스템의 성능에는 영향을 주지 않습니다. 따라서 최대 대화 상자나 일괄 작업 기간을 고려하지 않고 스냅샷 복사본 생성을 예약할 수 있습니다. SAP 및 NetApp 고객은 일반적으로 하루 동안 여러 온라인 Snapshot 백업을 예약합니다. 예를 들어, 6시간마다 공통된 환경을 의미합니다. 이러한 스냅샷 백업은 일반적으로 장기 보존을 위해 더 저렴한 스토리지로 계층화되거나 제거되기 전에 운영 스토리지 시스템에서 3~5일 동안 보관됩니다.
Snapshot 복사본은 복원 및 복구 작업에 대한 주요 이점을 제공합니다. NetApp SnapRestore 기술을 사용하면 전체 데이터베이스를 복원할 수 있고, 현재 사용 가능한 스냅샷 복사본을 기반으로 데이터베이스의 일부만 특정 시점으로 복원할 수 있습니다. 이러한 복원 프로세스는 데이터베이스 크기와 관계없이 몇 초 내에 완료됩니다. 하루 동안 여러 개의 온라인 Snapshot 백업을 생성할 수 있기 때문에 복구 프로세스에 필요한 시간이 기존의 일일 1회 백업 방식에 비해 크게 줄어듭니다. 최대 24시간이 아닌 몇 시간 전의 스냅샷 복사본으로 복원을 수행할 수 있으므로 포워드 복구 중에 적용해야 하는 트랜잭션 로그가 적습니다. 따라서 RTO는 기존 스트리밍 백업에 몇 시간이 아니라 몇 분으로 줄어듭니다.
스냅샷 복사본 백업은 활성 온라인 데이터와 동일한 디스크 시스템에 저장됩니다. 따라서 2차 위치에 대한 백업을 대체하는 대신 스냅샷 복사본 백업을 보완 자료로 사용할 것을 권장합니다. 대부분의 복구 및 복구 작업은 운영 스토리지 시스템에서 SnapRestore를 사용하여 관리합니다. 2차 위치에서의 복원은 스냅샷 복사본이 포함된 운영 스토리지 시스템이 손상된 경우에만 필요합니다. 기본 위치에서 더 이상 사용할 수 없는 백업을 복원해야 하는 경우 보조 위치도 사용할 수 있습니다.
2차 위치에 대한 백업은 운영 스토리지에 생성된 Snapshot 복사본을 기반으로 합니다. 따라서 SAP 데이터베이스 서버에서 로드를 생성하지 않고 운영 스토리지 시스템에서 직접 데이터를 읽습니다. 기본 스토리지는 보조 스토리지와 직접 통신하고 NetApp SnapVault 기능을 사용하여 백업 데이터를 대상에 복제합니다.
SnapVault는 기존 백업에 비해 뛰어난 이점을 제공합니다. 모든 데이터가 소스에서 대상으로 전송되는 초기 데이터 전송 후에는 이후의 모든 백업 복사본이 변경된 블록만 보조 스토리지로 이동합니다. 따라서 운영 스토리지 시스템의 부하와 전체 백업에 필요한 시간이 크게 줄어듭니다. SnapVault는 변경된 블록만 대상에 저장하므로 전체 데이터베이스 백업을 추가할 경우 디스크 공간이 훨씬 적게 사용됩니다.
Snapshot 백업 및 복원 작업의 런타임
다음 그림에서는 스냅샷 백업 작업을 사용하는 고객의 HANA Studio를 보여 줍니다. 이 이미지는 스냅샷 백업 기술을 사용하여 HANA 데이터베이스(약 4TB의 크기)를 1분 20초 이내에 백업하고 파일 기반 백업 작업에서 4시간 이상을 백업한다는 것을 보여줍니다.
전체 백업 워크플로우 런타임의 가장 큰 부분은 HANA 백업 세이브 포인트 작업을 실행하는 데 필요한 시간이며, 이 단계는 HANA 데이터베이스의 로드에 따라 달라집니다. 스토리지 스냅샷 백업 자체는 항상 몇 초 내에 완료됩니다.
복구 시간 목표 비교
이 섹션에서는 파일 기반 및 스토리지 기반 Snapshot 백업에 대한 RTO(복구 시간 목표) 비교를 제공합니다. RTO는 데이터베이스를 복원, 복구 및 시작하는 데 필요한 시간의 합계로 정의됩니다.
데이터베이스를 복원하는 데 필요한 시간입니다
파일 기반 백업을 사용할 경우 복원 시간은 데이터베이스 및 백업 인프라의 크기에 따라 달라지며, 이 크기는 초당 메가바이트 단위로 복원 속도를 정의합니다. 예를 들어, 인프라에서 250MBps의 속도로 복원 작업을 지원하는 경우 지속성 상태에서 데이터베이스 크기가 4TB로 복원하는 데 약 4.5시간이 걸립니다.
스토리지 스냅샷 복사본 백업을 사용하면 복원 시간이 데이터베이스 크기와 상관없으며 항상 몇 초 내에 유지됩니다.
데이터베이스를 시작하는 데 필요한 시간입니다
데이터베이스 시작 시간은 데이터베이스의 크기와 데이터를 메모리로 로드하는 데 필요한 시간에 따라 달라집니다. 다음 예에서는 데이터가 1000Mbps로 로드될 수 있다고 가정합니다. 4TB를 메모리에 로드하는 데 1시간 10분 정도 소요됩니다. 파일 기반 복구 및 스냅샷 기반 복원 및 복구 작업의 시작 시간은 동일합니다.
데이터베이스 복구에 필요한 시간
복구 시간은 복구 후 적용해야 하는 로그 수에 따라 달라집니다. 이 수는 데이터 백업을 수행하는 빈도에 따라 결정됩니다.
파일 기반 데이터 백업을 사용하면 백업 스케줄이 일반적으로 하루에 한 번 수행됩니다. 백업이 운영 성능을 저하하므로 일반적으로 백업 빈도를 높일 수 없습니다. 따라서 최악의 경우, 하루 동안 기록된 모든 로그는 순방향 복구 중에 적용해야 합니다.
스냅샷 백업은 SAP HANA 데이터베이스의 성능에 영향을 주지 않으므로 일반적으로 더 자주 스케줄됩니다. 예를 들어, 스냅샷 백업을 6시간마다 예약하는 경우 최악의 경우 복구 시간은 파일 기반 백업을 위한 복구 시간의 1/4입니다(6시간/24시간 = .25).
다음 그림에서는 다양한 스케줄을 사용하는 일일 파일 기반 백업 및 스냅샷 백업과 복구 작업을 비교하여 보여 줍니다.
처음 두 개의 막대는 하루에 Snapshot 백업을 하나만 하더라도 스냅샷 백업의 복원 작업 속도로 인해 복원 및 복구가 43%로 줄어들었다는 것을 보여 줍니다. 하루에 여러 개의 Snapshot 백업이 생성되는 경우 앞으로 복구 중에 적용해야 할 로그가 줄어들기 때문에 런타임을 더욱 줄일 수 있습니다.
다음 그림에서는 하루에 4~6개의 Snapshot 백업이 가장 적합하다는 것을 보여 줍니다. 이보다 더 높은 빈도는 더 이상 전체 런타임에 큰 영향을 주지 않기 때문입니다.
신속한 백업 및 클론 복제 작업의 사용 사례와 값
백업 실행은 모든 데이터 보호 전략에서 중요한 부분입니다. 시스템 장애로부터 복구할 수 있도록 정기적으로 백업이 예약됩니다. 이것이 가장 확실한 사용 사례이지만 백업 및 복구 작업의 속도가 더욱 빠른 것이 중요한 다른 SAP 라이프사이클 관리 작업도 있습니다.
SAP HANA 시스템 업그레이드는 업그레이드 전 주문형 백업과 업그레이드 실패 시 전체 계획된 다운타임을 크게 줄일 수 있는 복구 작업의 예입니다. 4TB 데이터베이스의 경우, 스냅샷 기반 백업 및 복원 작업을 통해 계획된 다운타임을 8시간 줄일 수 있습니다.
또 다른 사용 사례 예는 일반적인 테스트 주기를 예로 들 수 있습니다. 이 테스트 주기는 여러 데이터 세트 또는 매개 변수를 사용하여 여러 번 반복 테스트를 수행해야 합니다. 빠른 백업 및 복원 작업을 활용할 때 테스트 주기 내에 저장 지점을 쉽게 만들고 테스트를 통과하지 못하거나 반복해야 하는 경우 시스템을 이전 저장 지점으로 재설정할 수 있습니다. 따라서 테스트를 더 일찍 완료하거나 동시에 더 많은 테스트를 수행할 수 있으며 테스트 결과가 향상됩니다.
Snapshot 백업이 구축되면 HANA 데이터베이스 복사본이 필요한 다른 여러 사용 사례를 해결하는 데 사용될 수 있습니다. ONTAP용 FSx를 사용하면 사용 가능한 모든 스냅샷 백업의 컨텐츠를 기반으로 새 볼륨을 생성할 수 있습니다. 이 작업의 런타임은 볼륨의 크기와 관계없이 몇 초 정도 걸립니다.
가장 일반적인 사용 사례는 운영 시스템의 데이터를 테스트 또는 QA 시스템으로 복사해야 하는 SAP 시스템 새로 고침입니다. FSx for ONTAP 클론 생성 기능을 활용하면 몇 초 이내에 운영 시스템의 스냅샷 복사본에서 테스트 시스템에 대한 볼륨을 프로비저닝할 수 있습니다. 그런 다음 새 볼륨을 테스트 시스템에 연결하고 HANA 데이터베이스를 복구해야 합니다.
두 번째 활용 사례는 운영 시스템의 논리적 손상을 해결하는 데 사용되는 복구 시스템 생성입니다. 이 경우 운영 시스템의 이전 Snapshot 백업을 사용하여 복구 시스템을 시작합니다. 이 복구 시스템은 손상이 발생하기 전에 운영 시스템과 동일한 클론 복제본입니다. 그런 다음 복구 시스템을 사용하여 문제를 분석하고 손상된 데이터를 내보냅니다.
마지막 사용 사례는 복제를 중지하지 않고 재해 복구 장애 조치 테스트를 실행하는 기능이므로 재해 복구 설정의 RTO 및 RPO(복구 시점 목표)에 영향을 주지 않습니다. ONTAP용 FSx NetApp SnapMirror 복제를 사용하여 데이터를 재해 복구 사이트로 복제할 경우 재해 복구 사이트에서도 프로덕션 스냅샷 백업을 사용할 수 있으며 이를 사용하여 재해 복구 테스트를 위한 새 볼륨을 생성할 수 있습니다.
