모범 사례
SAP HANA 고가용성 개요
변경 제안
PDF
이 장에서는 애플리케이션 계층의 복제와 스토리지 복제를 비교하는 SAP HANA의 고가용성 옵션에 대해 간략하게 설명합니다.
SAP HANA 시스템 복제(HSR)
SAP HANA 시스템 복제는 데이터가 동기식으로 복제되고 메모리에 사전 로드되며 보조 호스트에서 지속적으로 업데이트되는 운영 모드를 제공합니다. 이 모드에서는 약 1분 이하의 매우 낮은 RTO 값을 사용할 수 있지만 소스 시스템에서 복제 데이터를 수신하는 데만 사용되는 전용 서버도 필요합니다. 또한 페일오버 시간이 짧기 때문에 HANA 소프트웨어 업그레이드와 같은 다운타임이 거의 없는 유지보수 작업에 SAP HANA 시스템 복제가 자주 사용됩니다. Linux 심장박동기 클러스터 솔루션은 일반적으로 장애 조치 작업을 자동화하는 데 사용됩니다.
운영 사이트, 스토리지, 호스트 또는 전체 사이트에서 장애가 발생하면 HANA 시스템이 Linux 심장박동기 클러스터에 의해 제어되는 보조 사이트로 자동으로 페일오버됩니다.
모든 구성 옵션 및 복제 시나리오에 대한 전체 설명은 을 참조하십시오 "SAP HANA 시스템 복제 ++ | + + SAP 도움말 포털".
NetApp SnapMirror 활성 동기화
SnapMirror 액티브 동기화를 사용하면 전체 사이트 장애가 발생하더라도 비즈니스 서비스를 계속 운영할 수 있으므로 보조 복사본을 사용하여 애플리케이션을 투명하게 페일오버할 수 있습니다. SnapMirror 활성 동기화로 페일오버를 트리거하는 데 수동 개입이나 사용자 지정 스크립팅이 필요하지 않습니다. SnapMirror 액티브 동기화는 AFF 클러스터, All-Flash SAN 어레이(ASA) 클러스터 및 C-Series(AFF 또는 ASA)에서 지원됩니다. SnapMirror 액티브 동기화는 iSCSI 또는 FCP LUN으로 애플리케이션을 보호합니다.
ONTAP 9.15.1부터 SnapMirror 액티브 동기화는 대칭 액티브/액티브 기능을 지원합니다. 대칭적인 액티브/액티브는 양방향 동기식 복제를 통해 보호된 LUN의 두 복사본에서 읽기 및 쓰기 I/O 작업을 지원하므로 두 LUN 복사본이 모두 로컬에서 I/O 작업을 제공할 수 있습니다.
자세한 내용은 에서 "ONTAP의 SnapMirror 활성 동기화 개요"확인할 수 있습니다.
HANA 베어 메탈
베어 메탈 서버에서 SAP HANA를 실행하는 경우 SnapMirror Active Sync를 사용하여 고가용성 스토리지 솔루션을 제공할 수 있습니다. 데이터는 동기식으로 복제되므로 RPO=0을 제공합니다.
스토리지 장애가 발생할 경우 HANA 시스템은 RTO=0을 제공하는 두 번째 FCP 경로를 사용하여 보조 사이트의 미러링된 복사본에 투명하게 액세스합니다.
호스트 또는 전체 사이트에 장애가 발생한 경우 장애가 발생한 호스트의 데이터에 액세스할 수 있도록 보조 사이트의 새 서버를 제공해야 합니다. 이 시스템은 일반적으로 프로덕션 시스템과 동일한 크기의 테스트 또는 QA 시스템으로, 이제 종료되고 프로덕션 시스템을 실행하는 데 사용됩니다. 보조 사이트의 LUN이 새 호스트에 연결되면 HANA 데이터베이스를 시작해야 합니다. 따라서 총 RTO는 호스트를 프로비저닝하는 데 필요한 시간과 HANA 데이터베이스의 시작 시간에 따라 달라집니다.
vMSC(vSphere Metro Storage Cluster)
FCP가 연결된 데이터 저장소를 사용하여 VMware 환경에서 SAP HANA를 실행하는 경우 SnapMirror 액티브 동기화를 사용하여 VMware Metro Storage Cluster를 구축할 수 있습니다. 이러한 설정에서는 HANA 시스템에서 사용하는 데이터 저장소가 보조 사이트에 동기식으로 복제됩니다.
스토리지 장애가 발생하면 ESX 호스트가 보조 사이트의 미러링된 복제본을 자동으로 액세스하여 RTO=0을 제공합니다.
호스트 또는 전체 사이트에 장애가 발생할 경우 vSphere HA를 사용하여 보조 ESX 호스트에서 HANA VM을 시작합니다. HANA VM이 실행 중일 때 HANA 데이터베이스를 시작해야 합니다. 따라서 총 RTO는 주로 HANA 데이터베이스의 시작 시간에 따라 달라집니다.
솔루션 비교
다음 표는 위에서 설명한 솔루션의 주요 특성을 요약한 것입니다.
| HANA 시스템 복제 | SnapMirror 활성 동기화 – 베어 메탈 | SnapMirror active sync – VMware vMSC | |
|---|---|---|---|
RPO에 대해 설명합니다 |
RPO = 0 + 동기식 복제 |
||
RTO 및 스토리지 장애입니다 |
RTO<1분 |
RTO = 0 + 투명한 스토리지 페일오버 |
|
RTO + 사이트 또는 호스트 장애 발생 시 |
RTO<1분 |
RTO: 서버 준비 및 HANA 데이터베이스 시작에 필요한 시간에 따라 다릅니다. |
RTO: HANA 데이터베이스 시작에 필요한 시간에 따라 다릅니다. |
페일오버 자동화 |
예, 보조 HSR 호스트에 대한 자동 장애 조치 심장박동기 클러스터에 의해 제어됩니다. |
예, 스토리지 장애입니다 아니요. 호스트 또는 사이트 장애입니다 (호스트 프로비저닝, 스토리지 리소스 연결, HANA 데이터베이스 시작) |
예, 스토리지 장애입니다 예, 호스트 또는 사이트 장애 발생 시 가능합니다 (vSphere HA로 자동화된 다른 사이트로 VM 페일오버, HANA 데이터베이스 시작) |
보조 사이트의 전용 서버가 필요합니다 |
예, 데이터를 메모리에 미리 로드하고 데이터베이스 시작 없이 빠른 장애 조치를 활성화하는 데 필요합니다. |
아니요, 서버는 장애 조치의 경우에만 필요합니다. 일반적으로 QA에 사용되는 서버는 프로덕션에 사용됩니다. |
아니요, ESX 호스트의 리소스는 페일오버 시에만 필요합니다. 일반적으로 그런 다음 QA 리소스를 프로덕션에 사용합니다. |
