모범 사례
있습니다
변경 제안
PDF
SAP HANA 호스트는 이중화된 10GbE 또는 더 빠른 네트워크 인프라를 사용하여 스토리지 컨트롤러에 연결됩니다. SAP HANA 호스트와 스토리지 컨트롤러 간의 데이터 통신은 NFS 프로토콜을 기반으로 합니다. 스위치 또는 네트워크 인터페이스 카드(NIC) 장애가 발생할 경우 내결함성이 있는 SAP HANA 호스트-스토리지 연결을 제공하려면 이중 스위칭 인프라가 필요합니다.
스위치는 호스트 레벨에서 단일 논리 엔터티로 표시되도록 포트 채널을 통해 개별 포트 성능을 통합할 수 있습니다.
AFF 시스템 제품군의 다양한 모델을 스토리지 계층에서 혼합하여 필요에 따라 확장하고 다양한 성능 및 용량 요구사항을 지원할 수 있습니다. 스토리지 시스템에 연결할 수 있는 SAP HANA 호스트의 최대 수는 SAP HANA 성능 요구 사항 및 사용되는 NetApp 컨트롤러 모델에 의해 정의됩니다. 필요한 디스크 쉘프의 수는 SAP HANA 시스템의 용량 및 성능 요구사항에 따라 결정됩니다.
다음 그림에서는 스토리지 HA(고가용성) 쌍에 연결된 8개의 SAP HANA 호스트를 포함하는 예제 구성을 보여 줍니다.
다음 그림에서는 VMware vSphere를 가상화 계층으로 사용하는 예를 보여 줍니다.
아키텍처는 두 가지 차원에서 확장할 수 있습니다.
-
스토리지 컨트롤러가 현재 SAP HANA 주요 성능 지표(KPI)를 충족할 만큼 충분한 성능을 제공한다면 기존 스토리지에 추가 SAP HANA 호스트 및 스토리지 용량을 연결합니다.
-
SAP HANA 호스트를 추가할 수 있도록 스토리지 용량을 추가하여 스토리지 시스템을 추가할 수 있습니다
다음 그림에서는 스토리지 컨트롤러에 더 많은 SAP HANA 호스트가 연결되는 구성의 예를 보여 줍니다. 이 예에서는 16개의 SAP HANA 호스트의 용량 및 성능 요구사항을 충족하기 위해 더 많은 디스크 쉘프가 필요합니다. 총 처리량 요구사항에 따라 스토리지 컨트롤러에 10GbE 또는 더 빠른 연결을 추가해야 합니다.
구축된 AFF 시스템과 별도로, 다음 그림과 같이 인증된 스토리지 컨트롤러를 추가하여 SAP HANA 환경을 확장할 수도 있습니다.
SAP HANA 백업
모든 NetApp 스토리지 컨트롤러에 있는 ONTAP 소프트웨어는 SAP HANA 데이터베이스를 백업하는 메커니즘을 제공하며, 작동 중에는 성능에 영향을 주지 않습니다. 스토리지 기반 NetApp Snapshot 백업은 SAP HANA 단일 컨테이너 및 단일 테넌트 또는 여러 테넌트가 있는 SAP HANA MDC(Multitenant Database Container) 시스템에서 완벽하게 지원되고 통합된 백업 솔루션입니다.
스토리지 기반 스냅샷 백업은 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 재해 복구(DR)는 스토리지 복제 기술을 사용하여 데이터베이스 계층 또는 스토리지 계층에서 수행할 수 있습니다. 다음 섹션에서는 스토리지 복제를 기반으로 하는 재해 복구 솔루션에 대해 간략하게 설명합니다.
SAP HANA 재해 복구 솔루션에 대한 자세한 내용은 를 참조하십시오 "TR-4646: 스토리지 복제를 사용한 SAP HANA 재해 복구".
SnapMirror 기반의 스토리지 복제
다음 그림에서는 로컬 DR 데이터 센터에 동기식 SnapMirror 복제를 사용하고 원격 DR 데이터 센터에 데이터를 복제하기 위한 비동기식 SnapMirror를 사용하는 3개 사이트 재해 복구 솔루션을 보여 줍니다.
동기식 SnapMirror를 사용하여 데이터 복제를 수행하면 0의 RPO가 제공됩니다. 운영 및 로컬 DR 데이터 센터 간의 거리는 약 100km로 제한됩니다.
운영 사이트와 로컬 DR 사이트 모두의 장애에 대한 보호는 비동기식 SnapMirror를 사용하여 데이터를 세 번째 원격 DR 데이터 센터에 복제하여 수행됩니다. RPO는 복제 업데이트 빈도와 전송 속도에 따라 달라집니다. 이론적으로 거리는 제한이 없지만, 이 제한은 전송해야 하는 데이터의 양과 데이터 센터 간에 사용 가능한 연결에 따라 달라집니다. 일반적인 RPO 값은 30분에서 여러 시간 사이입니다.
두 복제 방법에 대한 RTO는 주로 DR 사이트에서 HANA 데이터베이스를 시작하고 데이터를 메모리로 로드하는 데 필요한 시간에 따라 달라집니다. 데이터가 1000Mbps의 처리량으로 읽혀지는 것으로 가정하면 1TB의 데이터를 로드하는 데 약 18분이 걸립니다.
DR 사이트의 서버를 정상 운영 중에 개발/테스트 시스템으로 사용할 수 있습니다. 재해가 발생할 경우 개발/테스트 시스템을 종료하고 DR 운영 서버로 시작해야 합니다.
두 복제 방법 모두 RPO 및 RTO에 영향을 주지 않고 DR 워크플로우 테스트를 실행할 수 있도록 지원합니다. FlexClone 볼륨은 스토리지에 생성되며 DR 테스트 서버에 연결됩니다.
동기식 복제는 StrictSync 모드를 제공합니다. 어떤 이유로든 보조 스토리지에 대한 쓰기가 완료되지 않으면 애플리케이션 입출력이 실패하여 운영 스토리지 시스템과 보조 스토리지 시스템이 동일한지 확인합니다. SnapMirror 관계가 InSync 상태로 되돌아간 후에만 기본 애플리케이션에 대한 애플리케이션 입출력이 재개됩니다. 운영 스토리지에 장애가 발생할 경우 데이터 손실 없이 페일오버 후 보조 스토리지에서 애플리케이션 입출력을 재개할 수 있습니다. StrictSync 모드에서는 RPO가 항상 0입니다.
MetroCluster 기반의 스토리지 복제
다음 그림에서는 솔루션에 대한 대략적인 개요를 보여 줍니다. 각 사이트의 스토리지 클러스터는 로컬 고가용성을 제공하며 운영 워크로드에 사용됩니다. 각 사이트의 데이터는 다른 위치에 동기식으로 복제되며, 재해 페일오버 시 사용할 수 있습니다.
