SAP HANA Azure 가상 머신 스토리지 구성

  • 아티클

Azure에서는 SAP HANA를 실행하는 Azure VM에 적합한 다양한 스토리지 유형을 제공합니다. SAP HANA 배포에 고려할 수 있는 SAP HANA 인증 Azure 스토리지 유형은 다음과 같습니다.

이러한 디스크 유형에 대한 자세한 내용은 SAP 워크로드에 대한 Azure Storage 유형 및 디스크 유형 선택 문서를 참조하세요.

Azure는 Azure Standard 및 Premium Storage v1/v2의 VHD에 대한 두 가지 배포 방법을 제공합니다. Azure 관리 디스크를 Azure 블록 스토리지 배포에 활용하는 것이 좋습니다.

IOPS 및 스토리지 처리량에서 스토리지 유형 및 해당 SLA의 목록을 보려면 관리 디스크에 대한 Azure 설명서를 참조하세요.

Important

선택한 Azure 스토리지 유형과는 독립적으로 해당 스토리지에 사용되는 파일 시스템을 SAP에서 특정 운영 체제 및 DBMS에 대해 지원해야 합니다. SAP Support Note #2972496에는 SAP HANA를 포함하여 다양한 운영 체제 및 데이터베이스에 지원되는 파일 시스템이 나와 있습니다. 이는 SAP HANA가 어떤 작업이든 읽기 및 쓰기를 위해 액세스할 수 모든 볼륨에 적용됩니다. 특히 SAP HANA용 Azure에서 NFS를 사용하는 경우 이 문서의 뒷부분에서 설명한 대로 NFS 버전의 추가 제한 사항이 적용됩니다.

다양한 스토리지 유형에 대한 최소 SAP HANA 인증 조건은 다음과 같습니다.

  • Azure 프리미엄 저장소 v1 - /hana/log는 Azure 쓰기 가속기에 의해 지원되어야 합니다. /hana/data 볼륨은 Azure 쓰기 가속기를 사용하지 않는 프리미엄 스토리지 v1에 배치하거나 Ultra Disk에 배치할 수 있습니다. Azure Premium Storage v2 또는 Azure Premium SSD v2는 Azure 쓰기 가속기 사용을 지원하지 않습니다.
  • Azure Ultra Disk(최소한 /hana/log 볼륨용) - /hana/data 볼륨은 Azure 쓰기 가속기 없이 Premium Storage v1/v2에 배치하거나 Ultra Disk를 빠르게 다시 시작할 수 있도록 할 수 있습니다.
  • Azure NetApp Files 기반 NFS v4.1 볼륨(/hana/log 및 /hana/data용) - /hana/shared의 볼륨은 NFS v3 또는 NFS v4.1 프로토콜을 사용할 수 있습니다.

고객과의 경험을 바탕으로 /hana/data 및 /hana/log간에 다양한 스토리지 유형 결합 지원을 변경했습니다. Azure NetApp Files를 기반으로 HANA 및 NFS 공유에 대해 인증된 다양한 Azure 블록 스토리지의 사용을 결합하는 것이 지원됩니다. 예를 들어 필요한 짧은 대기 시간을 얻기 위해 /hana/data Premium Storage v1 또는 v2에 배치하고 /hana/log를 Ultra Disk Storage에 배치할 수 있습니다. /hana/data대한 ANF 기반 볼륨을 사용하는 경우 /hana/log 볼륨은 HANA 인증 Azure 블록 스토리지 유형 중 하나에도 배치할 수 있습니다. 볼륨(예: /hana/data) 및 Azure Premium Storage v1/v2 또는 다른 Ultra 볼륨(예: /hana/log)에서 ANF에 더해 NFS를 사용하는 것은 지원됩니다.

온-프레미스 환경의 경우 I/O 하위 시스템 및 해당 성능은 신경 쓸 필요가 거의 없었습니다. SAP HANA에 대한 최소 스토리지 요구 사항을 충족하는 것은 어플라이언스 공급업체의 몫이었기 때문입니다. 자체적으로 Azure 인프라를 빌드하는 동안에는 그러한 SAP 발행 요구 사항 몇 가지에 대해 알아야 합니다. SAP에서 권장하는 최소 처리량 특성 중 일부는 다음과 같습니다.

  • 250MB/초의 /hana/log에서 1MB I/O 크기로 읽기/쓰기
  • 16MB 및 64MB I/O 크기의 /hana/data에 대해 400MB/초 이상의 읽기 작업
  • 16MB 및 64MB I/O 크기의 /hana/data에 대해 250MB/초 이상의 쓰기 작업

낮은 스토리지 대기 시간이 DBMS 시스템에 중요하므로 SAP HANA와 같이 DBMS의 경우에도 데이터를 메모리 내에 유지합니다. 스토리지에서 중요한 경로는 일반적으로 DBMS 시스템의 트랜잭션 로그 쓰기입니다. 그러나 쓰기 저장점 또는 충돌 복구 후 메모리 내 데이터 로드와 같은 작업도 중요할 수 있습니다. 따라서 /hana/data 및 /hana/log 볼륨에 Azure Premium Storage v1/v2, Ultra Disk 또는 ANF를 사용하는 필수 입니다.

HANA에 대한 스토리지 구성을 선택하는 몇 가지 지침은 다음과 같이 나열할 수 있습니다.

  • SAP 워크로드에 대한 Azure Storage 유형 및 디스크 유형 선택을 기반으로 하여 스토리지 유형을 결정합니다.
  • VM 크기를 조정하거나 VM을 결정하는 경우 전체 VM I/O 처리량 및 IOPS 제한을 고려합니다. 전체 VM 스토리지 처리량은 메모리 최적화 가상 머신 크기 문서에 설명되어 있습니다.
  • 스토리지 구성을 결정하는 경우 /hana/data 볼륨 구성을 사용하여 VM의 전체 처리량 미만으로 유지합니다. SAP HANA 저장점을 작성하면, HANA에서 I/O를 적극적으로 실행할 수 있습니다. 저장점을 작성할 때 /hana/data 볼륨의 처리량 제한까지 쉽게 높일 수 있습니다. /hana/data 볼륨을 작성하는 디스크의 처리량이 VM에서 허용하는 것보다 더 높은 경우 저장점 쓰기에 사용되는 처리량이 다시 실행 로그 쓰기의 처리량 요구를 방해하는 상황이 발생할 수 있습니다. 이는 애플리케이션 처리량에 영향을 줄 수 있는 상황입니다.
  • HANA 시스템 복제 사용을 고려 중인 경우 각 복제본의 /hana/data에 사용되는 스토리지는 동일해야 하며 각 복제본의 /hana/log에 사용되는 스토리지 유형은 동일해야 합니다. 예를 들어 한 VM의 /hana/data에 대해 Azure Premium Storage v1을 사용하고 동일한 HANA 시스템 복제 구성의 복제본을 실행하는 다른 VM의 /hana/data에 대해 Azure Ultra Disk를 사용하는 것은 지원되지 않습니다.

Important

이 문서 또는 후속 문서의 스토리지 구성 제안 사항은 시작하기 위한 지침을 의미합니다. 워크로드를 실행하고 스토리지 사용률 패턴을 분석하면 제공된 모든 스토리지 대역폭 또는 IOPS를 활용하지 않는다는 것을 알 수 있습니다. 그러면 스토리지 크기를 줄이는 것을 고려할 수 있습니다. 또는 반대로 워크로드에는 이러한 구성에서 제안된 것보다 더 많은 스토리지 처리량이 필요할 수 있습니다. 따라서 더 많은 용량, IOPS 또는 처리량을 배포해야 할 수 있습니다. 필요한 스토리지 용량, 필요한 스토리지 대기 시간, 필요한 스토리지 처리량/IOPS 및 가장 저렴한 구성 사이의 긴장 상황에서 Azure는 사용자와 HANA 워크로드에 적합한 절충점을 찾고 조정할 수 있는 다양한 기능과 다양한 가격을 갖춘 다양한 스토리지 유형을 제공합니다.

스트라이프 세트 및 SAP HANA 데이터 볼륨 분할

Azure Premium Storage v1을 사용하면 여러 Azure 디스크에서 /hana/data 및/또는 /hana/log 볼륨을 스트라이프할 때 최상의 가격/성능 비율을 기록할 수 있습니다. 더 많은 IOPS 또는 처리량을 제공하는 더 큰 디스크 볼륨을 배포하는 대신, Linux의 일부인 LVM 및 MDADM 볼륨 관리자를 사용하여 여러 Azure 디스크에서 단일 볼륨을 만드는 작업을 수행할 수 있습니다. 디스크를 스트라이프하는 방법은 수십 년 전부터 사용되었으며 잘 알려져 있습니다. 필요한 IOPS 또는 처리량 기능을 달성하는 데 이러한 스트라이프 볼륨이 유익한 만큼 복잡성도 스트라이프 볼륨 관리에 추가됩니다. 특히 볼륨 용량을 확장해야 하는 경우 SAP는 적어도 /hana/data에 대해 여러 Azure 디스크에서 스트라이프하는 것과 동일한 목표를 달성하는 대체 방법을 도입했습니다. SAP HANA 2.0 SPS03부터 HANA 인덱스 서버는 여러 Azure 디스크에 있는 여러 HANA 데이터 파일에서 I/O 작업을 스트라이프할 수 있습니다. 이점은 여러 Azure 디스크에서 스트라이프 볼륨을 만들고 관리할 필요가 없다는 것입니다. 데이터 볼륨 분할의 SAP HANA 기능은 다음에 자세히 설명되어 있습니다.

자세히 살펴보면 이 기능을 적용하는 경우 볼륨 관리자 기반 스트라이프 세트의 복잡성이 제거된다는 것이 분명합니다. 또한 HANA 데이터 볼륨 분할이 Azure Premium Storage v1/v2와 같은 Azure 블록 스토리지에서만 작동하지 않는다는 것도 알 수 있습니다. IOPS 또는 처리량 제한이 NFS 공유에 있는 경우 이 기능을 사용하여 이러한 공유를 스트라이프할 수도 있습니다.

Linux I/O 스케줄러 모드

Linux에는 몇 가지 다른 I/O 일정 예약 모드가 있습니다. Linux 공급 업체 및 SAP를 통한 일반적인 권장 사항은 디스크 볼륨에 대한 I/O 스케줄러 모드를 mq-deadline 또는 kyber 모드에서 noop(다중 큐가 아님)로 다시 구성하거나, SLES saptune 프로필에서 아직 수행하지 않은 경우 (다중 큐) 모드에 대해 none으로 다시 구성하는 것입니다. 자세한 내용은 다음에서 참조했습니다.

Red Hat에서는 다른 SAP 애플리케이션에 대한 특정 튜닝 프로필에 설정된 설정을 그대로 유지합니다.

논리 볼륨 관리자를 사용하는 경우 스트라이프 크기

LVM 또는 mdadm을 사용하여 스트라이프 세트를 여러 Azure 프리미엄 디스크에 작성하는 경우 스트라이프 크기를 정의해야 합니다. 이러한 크기는 /hana/data와 /hana/log 간에 차이가 있습니다. 권장 사항: 스트라이프 크기에 따라 다음을 사용하는 것이 좋습니다.

  • /hana/data에 대해 256KB
  • /hana/log의 경우 64KB

참고 항목

/hana/data에 대한 스트라이프 크기는 최신 Linux 버전을 사용하는 고객 환경에 따라 64KB 또는 128KB를 요구하는 이전 권장 사항에서 256KB로 변경되었습니다. 256KB의 크기는 약간 더 나은 성능을 제공합니다. 또한 더 큰 I/O 크기를 사용하여 충분한 처리량을 얻기 위해 /hana/log의 스트라이프 크기에 대한 권장 사항이 32KB에서 64KB로 변경되었습니다.

참고 항목

Azure 블록 스토리지는 세 개의 VHD 이미지를 유지하므로 RAID 볼륨을 사용하여 중복 수준을 구성할 필요가 없습니다. 스트라이프 세트를 Azure 프리미엄 디스크에 사용하는 것은 전적으로 충분한 IOPS 및/또는 I/O 처리량을 제공하는 볼륨을 구성하는 것입니다.

여러 Azure Disks를 스트라이프 세트 아래에 누적하면 IOPS 및 스토리지 처리량 측면에서 누적되는 것입니다. 따라서 스트라이프 세트를 3 x P30 Azure 프리미엄 스토리지 v1 디스크에 배치하면 단일 Azure 프리미엄 스토리지 v1 P30 디스크의 3배의 IOPS 및 3배의 스토리지 처리량을 제공해야 합니다.

Important

LVM 또는 mdadm을 볼륨 관리자로 사용하여 스트라이프 세트를 여러 Azure 프리미엄 디스크에 만드는 경우 3개의 SAP HANA 파일 시스템, 즉 /data, /log 및 /shared를 기본 또는 루트 볼륨 그룹에 배치하면 안 됩니다. 일반적으로 /data, /log 및 /shared에 개별 볼륨 그룹을 만드는 Linux 공급 업체 지침을 따르는 것이 좋습니다.

HANA 공유 파일 시스템에 대한 고려 사항

HANA 파일 시스템의 크기를 조정하는 경우 데이터 및 로그 파일 HANA 시스템에 가장 주의를 기울입니다. 그러나 /hana/shared 는 HANA 이진 파일과 같은 필수 구성 요소를 호스트하므로 안정적인 HANA 시스템을 운영하는 데 중요한 역할을 합니다.
큰 덤프를 작성하는 동안 또는 집중 추적 중에 또는 백업이 /hana/shared 파일 시스템에 기록되는 경우와 같이 과도한 읽기/쓰기 작업으로 인해 /hana/shared가 I/O 포화 상태가 될 수 있습니다. 대기 시간도 증가할 수 있습니다.

HANA 시스템이 HA 구성에 있는 경우 공유 파일 시스템의 느린 응답(예: /hana/shared )으로 인해 클러스터 리소스 시간 제한이 발생할 수 있습니다. HANA 리소스 에이전트가 데이터베이스를 사용할 수 없다고 잘못 가정할 수 있으므로 이러한 시간 제한으로 인해 불필요한 장애 조치(failover)가 발생할 수 있습니다.

/hana/shared 권장 크기에 대한 SAP 지침은 다음과 같습니다.

볼륨 권장 크기
/hana/shared 스케일 업 최소(1TB, 1 x RAM)
/hana/shared 스케일 아웃 작업자 노드의 1 x RAM
4개 작업자 노드 당

자세한 내용은 다음 SAP 참고 사항을 참조하세요.
3288971 - FAQ: SAP HANA 시스템 복제 환경의 SUSE HAE/RedHat HAA Pacemaker 클러스터 리소스 관리자
1999930 - FAQ: SAP HANA I/O 분석

성능 병목 상태를 방지하기 위해 /hana/shared 크기를 지정하는 것이 가장 좋습니다. 크기가 좋은 /hana/shared 파일 시스템은 특히 HA 시나리오에서 SAP HANA 시스템의 안정성과 안정성에 기여합니다.

HANA에 대한 Azure Premium Storage v1 구성

Azure Premium Storage v1을 사용하는 자세한 HANA 스토리지 구성 권장 사항은 SAP HANA Azure 가상 머신 Premium SSD 스토리지 구성 문서를 참조하세요.

HANA에 대한 Azure 프리미엄 SSD v2 구성

Azure 프리미엄 ssd v2 스토리지를 사용하는 자세한 HANA 스토리지 구성 권장 사항은 SAP HANA Azure 가상 머신 Premium SSD v2 스토리지 구성 문서를 참조하세요.

SAP HANA용 Azure Ultra Disk 스토리지 구성

Azure Ultra Disk를 사용하는 자세한 HANA 스토리지 구성 권장 사항은 SAP HANA Azure 가상 머신 Ultra Disk Storage 구성 문서를 참조하세요.

Azure NetApp Files 기반 NFS v 4.1 볼륨

HANA용 ANF에 대한 자세한 내용은 SAP HANA용 Azure NetApp Files의 NFS v4.1 볼륨 문서를 참조하세요.

다음 단계

자세한 내용은 다음을 참조하세요.