TR-4614: SnapCenter를 통한 SAP HANA 백업 및 복구
변경 제안
PDF
오늘날 기업은 SAP 애플리케이션을 위해 중단 없는 지속적인 가용성을 필요로 합니다. 지속적으로 증가하는 데이터 볼륨이 요구되고 시스템 백업과 같은 일상적인 유지 관리 작업이 필요할 때 일관된 성능 수준을 기대합니다. SAP 데이터베이스 백업은 중요한 작업이며 운영 SAP 시스템에 상당한 성능 영향을 미칠 수 있습니다.
저자: 닐스 바우어, NetApp
백업 윈도우는 줄어들고 있으며, 백업할 데이터의 양은 계속 증가하고 있습니다. 따라서 비즈니스 프로세스에 미치는 영향을 최소화하면서 백업을 수행할 수 있는 시간을 찾기가 어렵습니다. SAP 운영 및 비운영 시스템의 다운타임을 최소화하여 데이터 손실과 비즈니스 비용을 절감해야 하기 때문에 SAP 시스템을 복원 및 복구하는 데 걸리는 시간이 문제가 됩니다.
다음은 SAP 백업 및 복구와 관련된 당면 과제를 요약한 것입니다.
-
* 운영 SAP 시스템에 대한 성능 영향 * 일반적으로 기존 복제 기반 백업은 데이터베이스 서버, 스토리지 시스템 및 스토리지 네트워크에 과부하가 발생하기 때문에 운영 SAP 시스템에서 상당한 성능 저하를 일으킬 수 있습니다.
-
* 백업 기간 단축 * SAP 시스템에서 진행 중인 대화 또는 배치 작업이 거의 없을 때만 기존 백업을 수행할 수 있습니다. SAP 시스템이 24시간 사용 중일 때는 백업 스케줄링이 더 어려워집니다.
-
* 빠른 데이터 증가. * 빠른 데이터 증가 및 백업 시간 단축을 위해서는 백업 인프라에 대한 지속적인 투자가 필요합니다. 즉, 더 많은 테이프 드라이브, 추가 백업 디스크 공간 및 더 빠른 백업 네트워크를 확보해야 합니다. 또한 이러한 테이프 자산의 저장 및 관리에 드는 지속적인 비용에도 포함해야 합니다. 증분 또는 차등 백업에서는 이러한 문제를 해결할 수 있지만 이 방식을 사용하면 매우 느리고 번거로우며 복잡한 복원 프로세스가 확인하기가 더 어렵습니다. 이러한 시스템은 일반적으로 비즈니스에 허용되지 않는 방식으로 RTO(복구 시간 목표) 및 RPO(복구 시점 목표) 시간을 늘립니다.
-
* 가동 중단 시간의 비용 증가. * SAP 시스템의 계획되지 않은 가동 중지 시간은 일반적으로 비즈니스 재무에 영향을 줍니다. 계획되지 않은 다운타임의 상당 부분은 SAP 시스템을 복원 및 복구하는 데 필요한 요구 사항에 의해 사용됩니다. 따라서 원하는 RTO는 백업 및 복구 아키텍처의 설계를 결정합니다.
-
* SAP 업그레이드 프로젝트를 위한 백업 및 복구 시간 * SAP 업그레이드를 위한 프로젝트 계획에는 SAP 데이터베이스의 백업이 3개 이상 포함됩니다. 이러한 백업은 업그레이드 프로세스에 사용할 수 있는 시간을 크게 줄여줍니다. 진행 결정은 일반적으로 이전에 생성된 백업에서 데이터베이스를 복원 및 복구하는 데 필요한 시간을 기준으로 합니다. 시스템을 이전 상태로 복원하는 것이 아니라 신속한 복원을 통해 업그레이드 중에 발생할 수 있는 문제를 해결하는 데 더 많은 시간을 할애할 수 있습니다.
제공하는 데 이 때 넷엡솔루션이 사용됩니다
NetApp Snapshot 기술을 사용하여 몇 분 내에 데이터베이스 백업을 생성할 수 있습니다. 스냅샷 복사본은 스토리지 플랫폼에서 물리적 데이터 블록을 이동하지 않으므로 스냅샷 복사본을 만드는 데 필요한 시간은 데이터베이스의 크기와 상관없습니다. 또한 스냅샷 복사본이 생성될 때 또는 액티브 파일 시스템의 데이터가 변경되면 NetApp Snapshot 기술이 데이터 블록을 이동하거나 복사하지 않기 때문에 스냅샷 기술을 사용하면 라이브 SAP 시스템에 성능이 영향을 주지 않습니다. 따라서 최대 대화 상자나 일괄 작업 기간을 고려하지 않고 스냅샷 복사본 생성을 예약할 수 있습니다. SAP 및 NetApp 고객은 일반적으로 하루 동안 여러 온라인 Snapshot 백업을 예약합니다. 예를 들어, 4시간마다 공통된 환경을 의미합니다. 이러한 스냅샷 백업은 일반적으로 운영 스토리지 시스템에서 제거되기 전에 3~5일 동안 보관됩니다.
Snapshot 복사본은 복원 및 복구 작업에 대한 주요 이점을 제공합니다. NetApp SnapRestore 데이터 복구 소프트웨어를 사용하면 전체 데이터베이스를 복원할 수 있고, 사용 가능한 스냅샷 복사본을 기반으로 데이터베이스의 일부를 특정 시점으로 복원할 수 있습니다. 이러한 복원 프로세스는 데이터베이스 크기와 관계없이 몇 분 내에 완료됩니다. 하루 동안 여러 개의 온라인 Snapshot 백업이 생성되므로 기존 백업 방식에 비해 복구 프로세스에 필요한 시간이 크게 단축됩니다. 최대 24시간이 아닌 단 몇 시간 만에 스냅샷 복사본을 사용해 복원을 수행할 수 있으므로 트랜잭션 로그를 줄일 수 있습니다. 따라서 RTO는 기존의 단일 주기 테이프 백업에 필요한 몇 시간이 아니라 몇 분으로 줄어듭니다.
스냅샷 복사본 백업은 활성 온라인 데이터와 동일한 디스크 시스템에 저장됩니다. 따라서 2차 위치에 대한 백업을 대체하는 대신 스냅샷 복사본 백업을 보완 자료로 사용할 것을 권장합니다. 대부분의 복구 및 복구 작업은 운영 스토리지 시스템에서 SnapRestore를 사용하여 처리됩니다. 2차 위치에서의 복원은 스냅샷 복사본이 포함된 운영 스토리지 시스템이 손상된 경우에만 필요합니다. 스냅샷 복사본에서 더 이상 사용할 수 없는 백업을 복원해야 하는 경우 보조 위치를 사용할 수도 있습니다. 예를 들어 월말 백업입니다.
2차 위치에 대한 백업은 운영 스토리지에 생성된 Snapshot 복사본을 기반으로 합니다. 따라서 SAP 데이터베이스 서버에서 로드를 생성하지 않고 운영 스토리지 시스템에서 직접 데이터를 읽습니다. 기본 스토리지는 보조 스토리지와 직접 통신하고 NetApp SnapVault D2D 백업을 사용하여 백업 데이터를 대상에 전송합니다.
SnapVault는 기존 백업에 비해 뛰어난 이점을 제공합니다. 모든 데이터가 소스에서 대상으로 전송되는 초기 데이터 전송 후 이후의 모든 백업에서는 변경된 블록만 보조 스토리지로 복사합니다. 따라서 운영 스토리지 시스템의 부하와 전체 백업에 필요한 시간이 크게 줄어듭니다. SnapVault는 변경된 블록만 대상에 저장하므로 전체 데이터베이스 백업에는 더 적은 디스크 공간이 필요합니다.
또한, 하이브리드 클라우드 운영 모델로 원활하게 확장할 수 있습니다. 재해 복구 또는 오프사이트 백업을 위한 데이터 복제는 사내 NetApp ONTAP 시스템에서 클라우드에서 실행되는 Cloud Volumes ONTAP 인스턴스까지 수행할 수 있습니다. SnapCenter를 사용하면 SAP HANA 시스템이 사내 또는 클라우드에서 실행되는 경우에 관계없이 데이터 보호 및 데이터 복제를 관리하기 위한 중앙 툴로 사용할 수 있습니다. 다음 그림에서는 백업 솔루션의 개요를 보여 줍니다.
Snapshot 백업의 런타임
다음 스크린샷은 NetApp 스토리지에서 SAP HANA를 실행하는 고객의 HANA Studio를 보여줍니다. 고객이 HANA 데이터베이스를 백업하기 위해 스냅샷 복사본을 사용합니다. 이 이미지는 Snapshot 백업 기술을 사용하여 HANA 데이터베이스(약 2.3TB 크기)가 2분 11초 내에 백업되는 것을 보여 줍니다.
|
전체 백업 워크플로우 런타임의 가장 큰 부분은 HANA 백업 저장점 작업을 실행하는 데 필요한 시간이며, 이 단계는 HANA 데이터베이스의 로드에 따라 달라집니다. 스토리지 스냅샷 백업 자체는 항상 몇 초 내에 완료됩니다. |
복구 시간 목표 비교
이 섹션에서는 파일 기반 및 스토리지 기반 Snapshot 백업에 대한 RTO 비교에 대해 설명합니다. RTO는 데이터베이스를 복구하는 데 필요한 시간과 데이터베이스를 시작하고 복구하는 데 필요한 시간의 합으로 정의됩니다.
데이터베이스를 복원하는 데 필요한 시간입니다
파일 기반 백업을 사용할 경우 복원 시간은 데이터베이스 및 백업 인프라의 크기에 따라 달라지며, 이 크기는 초당 메가바이트 단위로 복원 속도를 정의합니다. 예를 들어, 인프라에서 250MBps의 속도로 복원 작업을 지원하는 경우 데이터베이스 크기를 복원하는 데 약 1시간 10분이 소요됩니다.
스토리지 스냅샷 복사본 백업을 사용하면 복원 시간이 데이터베이스 크기와 상관없으며, 1차 스토리지에서 복원할 수 있는 경우 복원 시간이 몇 초 범위 내에 있습니다. 운영 스토리지를 더 이상 사용할 수 없는 경우 재해 발생 시에만 보조 스토리지에서 복구할 수 있습니다.
데이터베이스를 시작하는 데 필요한 시간입니다
데이터베이스 시작 시간은 행 및 열 저장소의 크기에 따라 달라집니다. 열 저장소의 경우 데이터베이스를 시작하는 동안 미리 로드된 데이터의 양에 따라 시작 시간도 달라집니다. 다음 예에서는 시작 시간이 30분이라고 가정합니다. 파일 기반 복원 및 복구와 스냅샷 기반의 복원 및 복구의 시작 시간은 동일합니다.
데이터베이스 복구에 필요한 시간
복구 시간은 복구 후 적용해야 하는 로그 수에 따라 달라집니다. 이 수는 데이터 백업을 수행하는 빈도에 따라 결정됩니다.
파일 기반 데이터 백업을 사용하면 백업 스케줄이 일반적으로 하루에 한 번 수행됩니다. 백업이 운영 성능을 저하하므로 일반적으로 백업 빈도를 높일 수 없습니다. 따라서 최악의 경우, 하루 동안 기록된 모든 로그는 순방향 복구 중에 적용해야 합니다.
스토리지 스냅샷 복사본 데이터 백업은 SAP HANA 데이터베이스의 성능에 영향을 미치지 않으므로 일반적으로 더 자주 예약됩니다. 예를 들어 스냅샷 복사본 백업이 6시간마다 예약되는 경우 복구 시간은 최악의 경우 파일 기반 백업을 위한 복구 시간의 1/4입니다(6시간/24시간 = 1/2로).
다음 그림에서는 파일 기반 데이터 백업을 사용할 때 1TB 데이터베이스에 대한 RTO 예를 보여 줍니다. 이 예에서는 백업이 하루에 한 번 수행됩니다. RTO는 복원 및 복구를 수행한 시기에 따라 다릅니다. 백업을 수행한 직후 복원 및 복구를 수행한 경우 RTO는 주로 복원 시간(예: 1시간 10분)을 기준으로 합니다. 복구 및 복구가 수행된 후 다음 백업이 수행되기 바로 전에 2시간 50분으로 증가했으며 최대 RTO는 4시간 30분으로 증가했습니다.
다음 그림에서는 스냅샷 백업을 사용할 때의 1TB 데이터베이스에 대한 RTO 예를 보여 줍니다. 스토리지 기반 Snapshot 백업의 경우 RTO는 데이터베이스 크기와 관계없이 몇 초 내에 복원이 완료되므로 데이터베이스 시작 시간과 복구 전달 시간에 따라 달라집니다. 또한 복구 및 복구가 수행되는 시기에 따라 복구 시간이 증가하지만 백업 빈도가 높기 때문에(이 예에서는 6시간마다) 복구 전달 시간은 최대 43분입니다. 이 예에서 최대 RTO는 1시간 13분입니다.
다음 그림에서는 서로 다른 데이터베이스 크기와 서로 다른 Snapshot 백업 빈도에 대한 파일 기반 및 스토리지 기반 Snapshot 백업의 RTO 비교를 보여 줍니다. 녹색 막대는 파일 기반 백업을 보여줍니다. 다른 막대는 백업 빈도가 서로 다른 스냅샷 복사본 백업을 보여 줍니다.
Snapshot 복사본 데이터를 매일 단일 백업할 경우 파일 기반 데이터 백업에 비해 RTO가 40% 이미 줄어듭니다. 하루에 4개의 스냅샷 백업을 수행하면 이 감소율이 70%로 증가합니다. 또한 이 그림에서는 스냅샷 백업 빈도를 하루 4-6개 이상의 Snapshot 백업으로 늘릴 경우 곡선이 일정하다는 것을 보여 줍니다. 따라서 NetApp 고객은 일반적으로 하루에 4~6개의 스냅샷 백업을 구성합니다.
|
|
그래프에는 HANA 서버 RAM 크기가 표시됩니다. 메모리의 데이터베이스 크기는 서버 RAM 크기의 절반으로 계산됩니다. |
|
|
복구 및 복구 시간은 다음 가정을 기반으로 계산됩니다. 데이터베이스는 250MBps로 복원할 수 있습니다. 하루 로그 파일 수는 데이터베이스 크기의 50%입니다. 예를 들어 1TB 데이터베이스는 하루에 500MB의 로그 파일을 생성합니다. 100Mbps로 복구를 수행할 수 있습니다. |