SSD 구성의 SAP HANA에서는 인라인 중복제거, 볼륨 간 인라인 중복제거, 인라인 압축, 인라인 컴팩션이 지원됩니다.

HDD 기반 구성에서 스토리지 효율성 기능을 사용하도록 설정하는 것은 지원되지 않습니다.

SAP HANA에서는 NVE(NetApp Volume Encryption) 및 NAE(NetApp Aggregate Encryption)를 사용할 수 있습니다.

QoS를 사용하면 공유 사용 컨트롤러에서 특정 SAP HANA 시스템 또는 기타 애플리케이션의 스토리지 처리량을 제한할 수 있습니다. 한 가지 사용 사례는 개발 및 테스트 시스템의 처리량을 제한하여 혼합 설정에서 운영 시스템에 영향을 주지 않도록 하는 것입니다.

사이징 프로세스 중에 비운영 시스템의 성능 요구사항을 결정해야 합니다. 개발 및 테스트 시스템은 일반적으로 SAP에서 정의한 운영 시스템 KPI의 20% ~ 50% 범위에서 낮은 성능 값으로 사이징할 수 있습니다.

ONTAP 9부터 QoS는 스토리지 볼륨 레벨에 구성되어 있으며 처리량(MBps)과 I/O 양(IOPS)에 대해 최대 값을 사용합니다.

대규모 쓰기 I/O는 스토리지 시스템에 가장 큰 성능 영향을 미칩니다. 따라서 QoS 처리량 제한은 데이터 및 로그 볼륨에서 해당 쓰기 SAP HANA 스토리지 성능 KPI 값의 백분율로 설정해야 합니다.

SAP HANA 시스템의 액티브 운영 파일 시스템에 NetApp FabricPool 기술을 사용하면 안 됩니다. 여기에는 데이터 및 로그 영역을 위한 파일 시스템과 '/HANA/공유' 파일 시스템이 포함됩니다. 따라서 특히 SAP HANA 시스템을 시작할 때 성능을 예측할 수 없습니다.

"스냅샷 전용" 계층화 정책을 사용하는 것은 물론 SnapVault 또는 SnapMirror 대상과 같은 백업 대상에서 FabricPool를 일반적으로 사용할 수도 있습니다.

FabricPool는 로그 백업을 다른 스토리지 계층으로 이동하는 데 적합한 옵션입니다. 백업을 이동하면 SAP HANA 데이터베이스를 복구하는 데 필요한 시간이 달라집니다. 따라서 "dediing-minimum-cooling-days" 옵션을 로컬 고속 스토리지 계층에 복구를 위해 정기적으로 필요한 로그 백업을 배치하는 값으로 설정해야 합니다.

다음 개요에는 필요한 스토리지 구성 단계가 요약되어 있습니다. 각 단계는 다음 섹션에서 자세히 설명합니다. 이 섹션에서는 스토리지 하드웨어가 설정되어 있고 ONTAP 소프트웨어가 이미 설치되어 있다고 가정합니다. 또한 스토리지 포트(10GbE 이상)와 네트워크 간의 연결이 이미 구성되어 있어야 합니다.

HDD를 사용할 경우 다음 그림과 같이 최대 2개의 DS2246 디스크 쉘프 또는 4개의 DS224C 디스크 쉘프를 하나의 SAS 스택에 연결하여 SAP HANA 호스트에 필요한 성능을 제공할 수 있습니다. 각 쉘프 내의 디스크는 HA 쌍의 두 컨트롤러에 균등하게 분산되어야 합니다.

SSD를 사용할 경우, 다음 그림과 같이 하나의 SAS 스택에 최대 하나의 디스크 쉘프를 연결하여 SAP HANA 호스트에 필요한 성능을 제공할 수 있습니다. 각 쉘프 내의 디스크는 HA 쌍의 두 컨트롤러에 균등하게 분산되어야 합니다. DS224C 디스크 쉘프를 사용하면 4중 경로 SAS 케이블도 사용할 수 있지만 필수는 아닙니다.

일반적으로 사용되는 디스크 쉘프 또는 드라이브 기술(SSD 또는 HDD)에 관계없이 컨트롤러당 2개의 애그리게이트를 구성해야 합니다. FAS2000 시리즈 시스템의 경우 데이터 애그리게이트 하나가 충분합니다.

SAP HANA 데이터베이스를 사용하는 여러 SAP 환경에서 단일 SVM을 사용할 수 있습니다. 필요한 경우 회사 내의 서로 다른 팀에서 SVM을 관리하는 경우 각 SAP 환경에 SVM을 할당할 수 있습니다.

새 SVM 생성 중에 QoS 프로필이 자동으로 생성되어 할당되었다면 SVM에서 자동으로 생성된 프로필을 제거하여 SAP HANA에 필요한 성능을 제공하십시오.

SAP HANA 운영 시스템의 경우 SAP HANA 호스트의 데이터 볼륨과 로그 볼륨을 마운트하기 위해 다른 LIF를 사용해야 합니다. 따라서 LIF가 두 개 이상 필요합니다.

서로 다른 SAP HANA 호스트의 데이터 및 로그 볼륨 마운트는 동일한 LIF를 사용하거나 각 마운트마다 개별 LIF를 사용하여 물리적 스토리지 네트워크 포트를 공유할 수 있습니다.

다음 표에는 물리적 인터페이스당 최대 데이터 및 로그 볼륨 마운트 수가 나와 있습니다.

개발 및 테스트 시스템에서는 물리적 네트워크 인터페이스에서 더 많은 데이터와 볼륨 마운트 또는 LIF를 사용할 수 있습니다.

운영, 개발, 테스트 시스템의 경우 '/HANA/공유' 파일 시스템은 데이터 또는 로그 볼륨과 동일한 LIF를 사용할 수 있습니다.

다음 그림은 4개의 단일 호스트 SAP HANA 시스템의 볼륨 구성을 보여줍니다. 각 SAP HANA 시스템의 데이터 및 로그 볼륨은 서로 다른 스토리지 컨트롤러에 분산됩니다. 예를 들어, 볼륨 'sid1_data_mnt00001'은 컨트롤러 A에 구성되고 볼륨 'sid1_log_mnt00001'은 컨트롤러 B에 구성됩니다

각 SAP HANA DB 호스트마다 데이터 볼륨, 로그 볼륨 및 '/HANA/shared'에 대한 볼륨이 구성됩니다. 다음 표에서는 단일 호스트 SAP HANA 시스템에 대한 구성 예를 보여 줍니다.

다음 표에서는 단일 호스트 시스템의 마운트 지점 구성의 예를 보여 줍니다. 중앙 스토리지에 'sidadm' 사용자의 홈 디렉토리를 배치하려면 'sid_shared' 볼륨에서 '/usr/sap/sid' 파일 시스템을 마운트해야 합니다.

다음 그림은 4+1 SAP HANA 시스템의 볼륨 구성을 보여줍니다. 각 SAP HANA 호스트의 데이터 및 로그 볼륨은 서로 다른 스토리지 컨트롤러에 분산됩니다. 예를 들어, 볼륨 'sid1_data1_mnt00001'은 컨트롤러 A에 구성되고 볼륨 'sid1_log1_mnt00001'은 컨트롤러 B에 구성됩니다

각 SAP HANA 호스트에 대해 데이터 볼륨과 로그 볼륨이 생성됩니다. '/HANA/Shared' 볼륨은 SAP HANA 시스템의 모든 호스트에서 사용됩니다. 다음 표에서는 4개의 활성 호스트가 있는 다중 호스트 SAP HANA 시스템에 대한 구성 예를 보여 줍니다.

다음 표에는 4개의 활성 SAP HANA 호스트가 있는 다중 호스트 시스템의 구성 및 마운트 지점이 나와 있습니다. 각 호스트의 'sidadm' 사용자의 홈 디렉토리를 중앙 스토리지에 배치하기 위해 'sid_shared' 볼륨에서 /usr/sap/sid' 파일 시스템이 마운트된다.

모든 SVM에서 다음 표에 나열된 볼륨 옵션을 확인하고 설정해야 합니다. 일부 명령의 경우 ONTAP 내의 고급 권한 모드로 전환해야 합니다.

다음 표에 나열된 NFS 옵션을 확인하여 모든 스토리지 컨트롤러에서 설정해야 합니다.

표시된 명령 중 일부의 경우 ONTAP 내의 고급 권한 모드로 전환해야 합니다.

다음 표에 나열된 NFS 옵션을 확인하여 모든 SVM에서 설정해야 합니다.

일부 명령의 경우 ONTAP 내의 고급 권한 모드로 전환해야 합니다.

호스트 자동 페일오버가 있는 SAP HANA 다중 호스트 시스템을 사용하는 경우 페일오버 매개 변수를 내에서 조정해야 합니다 nameserver.ini 다음 표와 같습니다. 이 섹션 내에서 기본 재시도 간격을 10초로 유지합니다.

볼륨이 생성되면 볼륨을 네임스페이스에 마운트해야 합니다. 이 문서에서는 접합 경로 이름이 볼륨 이름과 같다고 가정합니다. 기본적으로 볼륨은 기본 정책으로 내보내집니다. 필요한 경우 엑스포트 정책을 적용할 수 있습니다.