있습니다
변경 제안
PDF
SAP HANA 호스트는 이중화된 FCP 인프라 및 다중 경로 소프트웨어를 사용하여 스토리지 컨트롤러에 연결됩니다. 스위치 또는 HBA(호스트 버스 어댑터)에 장애가 발생할 경우 내결함성이 있는 SAP HANA 호스트-스토리지 연결을 제공하려면 이중화된 FCP 스위치 인프라가 필요합니다. 모든 HANA 호스트가 스토리지 컨트롤러의 필요한 LUN에 도달할 수 있도록 스위치에서 적절한 조닝을 구성해야 합니다.
AFF 시스템 제품군의 다양한 모델을 스토리지 계층에서 혼합하여 필요에 따라 확장하고 다양한 성능 및 용량 요구사항을 지원할 수 있습니다. 스토리지 시스템에 연결할 수 있는 SAP HANA 호스트의 최대 수는 SAP HANA 성능 요구 사항 및 사용되는 NetApp 컨트롤러 모델에 의해 정의됩니다. 필요한 디스크 쉘프의 수는 SAP HANA 시스템의 용량 및 성능 요구사항에 따라 결정됩니다.
다음 그림에서는 스토리지 HA 쌍에 연결된 8개의 SAP HANA 호스트를 포함하는 예제 구성을 보여 줍니다.
이 아키텍처는 두 가지 차원에서 확장할 수 있습니다.
-
스토리지 컨트롤러가 현재 SAP HANA KPI를 충족할 수 있는 충분한 성능을 제공할 경우 기존 스토리지에 추가 SAP HANA 호스트 및 스토리지 용량을 연결합니다
-
SAP HANA 호스트를 추가할 수 있도록 스토리지 용량을 추가하여 스토리지 시스템을 추가할 수 있습니다
다음 그림에서는 스토리지 컨트롤러에 더 많은 SAP HANA 호스트가 연결되는 구성 예를 보여 줍니다. 이 예에서는 16개의 SAP HANA 호스트의 용량 및 성능 요구사항을 충족하기 위해 더 많은 디스크 쉘프가 필요합니다. 총 처리량 요구사항에 따라 스토리지 컨트롤러에 FC 연결을 더 추가해야 합니다.
구축된 AFF 시스템과 별도로, 다음 그림과 같이 인증된 스토리지 컨트롤러를 추가하여 SAP HANA 환경을 확장할 수도 있습니다.
SAP HANA 백업
모든 NetApp 스토리지 컨트롤러에 있는 ONTAP 소프트웨어는 SAP HANA 데이터베이스를 백업하는 메커니즘을 제공하며, 작동 중에는 성능에 영향을 주지 않습니다. 스토리지 기반 NetApp Snapshot 백업은 SAP HANA 단일 컨테이너와 단일 테넌트 또는 여러 테넌트가 있는 SAP HANA MDC 시스템에 사용할 수 있는 완벽하게 지원되고 통합된 백업 솔루션입니다.
스토리지 기반 스냅샷 백업은 SAP HANA용 NetApp SnapCenter 플러그인을 사용하여 구현됩니다. 따라서 사용자는 SAP HANA 데이터베이스에서 기본적으로 제공되는 인터페이스를 사용하여 일관된 스토리지 기반 Snapshot 백업을 생성할 수 있습니다. SnapCenter는 각 스냅샷 백업을 SAP HANA 백업 카탈로그에 등록합니다. 따라서 SnapCenter에서 수행한 백업은 SAP HANA Studio 또는 Cockpit 내에서 볼 수 있으며 여기에서 복구 및 복구 작업을 위해 직접 선택할 수 있습니다.
NetApp SnapMirror 기술을 사용하면 하나의 스토리지 시스템에 생성된 스냅샷 복사본을 SnapCenter에서 제어하는 보조 백업 스토리지 시스템에 복제할 수 있습니다. 그런 다음 운영 스토리지의 각 백업 세트 및 보조 스토리지 시스템의 백업 세트에 대해 서로 다른 백업 보존 정책을 정의할 수 있습니다. SAP HANA용 SnapCenter 플러그인은 백업 카탈로그 관리를 포함하여 Snapshot 복사본 기반 데이터 백업 및 로그 백업의 보존을 자동으로 관리합니다. SAP HANA용 SnapCenter 플러그인을 사용하면 파일 기반 백업을 실행하여 SAP HANA 데이터베이스의 블록 무결성 검사를 실행할 수도 있습니다.
다음 그림과 같이 NFS 마운트를 사용하여 데이터베이스 로그를 보조 스토리지에 직접 백업할 수 있습니다.
스토리지 기반 Snapshot 백업은 기존의 파일 기반 백업에 비해 상당한 이점을 제공합니다. 이러한 이점에는 다음이 포함되지만 이에 국한되지는 않습니다.
-
신속한 백업(몇 분)
-
스토리지 계층의 복구 시간이 훨씬 더 빨라지고(몇 분) 백업을 더 자주 수행하므로 RTO가 감소됩니다
-
백업 및 복구 작업 중에 SAP HANA 데이터베이스 호스트, 네트워크 또는 스토리지의 성능 저하가 없습니다
-
블록 변경을 기반으로 공간 효율적이고 대역폭 효율적인 2차 스토리지 복제
SAP HANA 백업 및 복구 솔루션에 대한 자세한 내용은 를 참조하십시오."TR-4614: SnapCenter를 통한 SAP HANA 백업 및 복구"
SAP HANA 재해 복구
SAP HANA 재해 복구는 스토리지 복제 기술을 사용하여 데이터베이스 계층 또는 스토리지 계층에서 수행할 수 있습니다. 다음 섹션에서는 스토리지 복제를 기반으로 하는 재해 복구 솔루션에 대해 간략하게 설명합니다.
SAP HANA 재해 복구 솔루션에 대한 자세한 내용은 를 참조하십시오"TR-4646: 스토리지 복제를 사용한 SAP HANA 재해 복구".
SnapMirror 기반의 스토리지 복제
다음 그림은 로컬 재해 복구 데이터센터에 동기식 SnapMirror 액티브 싱크를 사용하고, 원격 재해 복구 데이터센터에 비동기식 SnapMirror를 사용하여 데이터를 복제하는 3개 사이트 재해 복구 솔루션을 보여줍니다. SnapMirror 액티브 싱크는 사이트 전체에 장애가 발생하더라도 비즈니스 서비스가 계속 운영될 수 있도록 지원하며, 보조 복사본(RPO=0, RTO=0)을 사용하여 애플리케이션이 투명하게 장애 조치(failover)되도록 지원합니다. SnapMirror 활성 동기화로 페일오버를 트리거하는 데 수동 개입이나 사용자 지정 스크립팅이 필요하지 않습니다. ONTAP 9.15.1부터 SnapMirror 액티브 동기화는 대칭 액티브/액티브 기능을 지원합니다. 대칭적인 액티브/액티브는 양방향 동기식 복제를 통해 보호된 LUN의 두 복사본에서 읽기 및 쓰기 I/O 작업을 지원하므로 두 LUN 복사본이 모두 로컬에서 I/O 작업을 제공할 수 있습니다.
자세한 내용은 에서 "ONTAP의 SnapMirror 활성 동기화 개요"확인할 수 있습니다.
비동기 SnapMirror 복제의 RTO는 주로 DR 사이트에서 HANA 데이터베이스를 시작하고 데이터를 메모리에 로드하는 데 필요한 시간에 따라 달라집니다. 데이터가 1000Mbps의 처리량으로 읽혀지는 것으로 가정하면 1TB의 데이터를 로드하는 데 약 18분이 걸립니다.
DR 사이트의 서버를 정상 운영 중에 개발/테스트 시스템으로 사용할 수 있습니다. 재해가 발생할 경우 개발/테스트 시스템을 종료하고 DR 운영 서버로 시작해야 합니다.
두 복제 방법 모두 RPO 및 RTO에 영향을 주지 않고 DR 워크플로우 테스트를 실행할 수 있도록 지원합니다. FlexClone 볼륨은 스토리지에 생성되며 DR 테스트 서버에 연결됩니다.
NetApp MetroCluster 기반의 스토리지 복제
다음 그림에서는 솔루션에 대한 대략적인 개요를 보여 줍니다. 각 사이트의 스토리지 클러스터는 로컬 고가용성을 제공하며 운영 워크로드에 사용됩니다. 각 사이트의 데이터는 다른 위치에 동기식으로 복제되며, 재해 페일오버 시 사용할 수 있습니다.
