Azure Netapp Files DB 정합성 스냅샷 찍기
Netapp은 On-premise Storage 시스템 시절부터 Ontap Snapshot 기능을 이용하여 빠르고, 용량 효율적이고, 백업 및 복구가 확실한 Database 스냅샷 기능을 지원해 왔다. 특히 SAP 글로벌 테크놀로지 파트너로서 SAP HANA에 좀 더 최적화 된 Snapshot을 지원해 왔다.
Azure Netapp Files에서도 이러한 대규모 사이즈의 엔터프라이즈 레벨의 Snapshot을 지원한다. 다만, 이런 환경에서의 DB 백업은 늘 고민거리를 같이 가져다 준다. 고객사에서 기준으로 잡고 있는 RPO(Recovery Point in Time)와 RTO(Recovery Time Objective)를 충족시켜야 하며, 백업을 하는데에 소모 되는 다운타임을 줄여 SLA를 충족시켜야 한다. 이러한 필요성에 의해서 application-consistent Snapshot이 개발되었다.
A. 스토리지 스냅샷의 장점
- DB 리소스 절약 : 스냅샷이 스토리지에 저장되기 때문에, DB 리소스를 점유하지 않는다
- 분 단위레벨로 RTO 달성 : data Snapshot에서 복구하는 것이 data backup에서 복구하는 것보다 매우 빠르다
- RTO를 더욱 짧게 : 스냅샷은 DB 백업과 달리 매우 빠르게 생성할 수 있다. 빠르게 생성하면 스냅샷은 더 자주 찍을 수 있다. 더 자주 찍게 되면 스냅샷 간 발생하는 LOG 백업의 양도 줄어들거 되어, 복구 시에 반영해야 할 LOG 백업의 양이 적어 복구 시간이 단축된다.
도식화된 그림을 보면,
DB에서 수행하는 기존 백업의 방식인데, Full DB 익스포트가 수행된다. DB 사이즈도 크고, 동시에 전송할 수 있는 밴드위스의 제한으로 백업 생성에 몇 시간 이상이 걸린다. 당연히, 하루에 수행할 수 있는 백업본의 개수는 1~2개 정도 밖에 되지 않는다. 게다가 복구시간은 백업 수행 시간보다 더 오래 걸린다.
스냅샷 기반의 백업은 이야기가 달라진다. 하루에 수행 할 수 있는 백업의 개수가 확연히 늘어나며(스냅샷이 초단위로 수행됨), Recovery 시간도 확연히 줄어들게 되는데, snapshot 생성 이후 반영해야할 redo 로그의 양이 적기 때문이다.
B. DB Application Consistent Snapshot 수행 예시 (SAP HANA)
- SAP HANA data 볼륨 데이터의 정합성을 보장하기 위해, internal savepoint를 찍는 SAP 커맨드가 있다.
- ANF SNAPSHOT을 수행한다
- ANF Snapshot을 완료한 후에, SAP HANA에서 backup을 종료한다.
C. DB Application Consistent Snapshot 수행 예시 — 자동화 (SAP HANA)
Python으로 해당 프로시져를 자동화한 예시이다. HANA backup catalog의 backup entry를 ANF Snapshot copy와 매핑시키기 위해 External-ID Cli parameter를 사용한 것을 볼 수 있다. 이렇게 하면 SAP HANA backup 카탈로그에서 ANF Snapshot을 인식하여 복구 오퍼레이션을 수행할 수 있다.
Azure NetApp Files SAP HANA backup in seconds — YouTube
C. Azure Application Consistent Snapshot
위와 같은 오퍼레이션을 Microsoft에서 지원하는 툴이 있는데, AzAcSnap 이라고 부른다.
Azure NetApp Files에 대한 Azure 애플리케이션 일치 스냅샷 도구는 무엇인가요? | Microsoft Docs
Azure Netapp Files에서 현재 지원되는 데이터베이스는 SAP HANA가 있으며, Oracle은 Preview 단계에 있다.