편집

Azure의 스케일업 아키텍처에서 Linux 가상 머신용 SAP HANA 실행

Azure
Azure Virtual Machines

이 참조 아키텍처는 Azure에서 재해 복구를 지원하는 고가용성 스케일 업 환경에서 SAP HANA를 실행하는 검증된 사례 세트를 보여 줍니다. 이 구현은 데이터베이스 계층에만 중점을 둡니다.

Architecture

이 참조 아키텍처는 일반적인 프로덕션 시스템을 설명합니다. 조직의 요구 사항에 맞게 가상 머신 크기를 선택할 수 있습니다. 비즈니스 요구 사항에 따라 이 구성을 하나의 가상 머신으로 줄일 수도 있습니다.

다음 다이어그램은 Azure의 SAP HANA에 대한 참조 아키텍처를 보여줍니다.

지역 배포 아키텍처를 보여 주는 다이어그램.

이 문서의 다이어그램이 포함된 Visio 파일을 다운로드합니다.

참고 항목

이 참조 아키텍처를 배포하려면 적절한 SAP 제품 및 기타 Microsoft 이외의 기술이 필요합니다.

워크플로

이 참조 아키텍처는 시스템 가용성을 최대화하기 위해 고가용성 배포에서 Azure에서 실행되는 일반적인 SAP HANA 데이터베이스에 대해 설명합니다. 아키텍처 및 해당 구성 요소는 비즈니스 요구 사항(RTO, RPO, 가동 시간 기대치, 시스템 역할)에 따라 사용자 지정될 수 있으며 잠재적으로 단일 VM으로 축소될 수 있습니다. 네트워크 레이아웃은 이러한 SAP 환경의 아키텍처 보안 주제를 시연하기 위해 간소화되었으며 이는 전체 엔터프라이즈 네트워크를 설명하기 위한 것은 아닙니다.

네트워킹

가상 네트워크 Azure Virtual Network 서비스는 보안 강화를 통해 Azure 리소스를 서로 연결합니다. 이 아키텍처에서 가상 네트워크는 hub-spoke 토폴로지의 허브에 배포된 ExpressRoute 게이트웨이를 통해 온-프레미스 환경에 연결합니다. SAP HANA 데이터베이스는 자체 스포크 가상 네트워크에 포함되어 있습니다. 스포크 가상 네트워크에는 데이터베이스 VM(가상 머신)에 대한 하나의 서브넷이 포함됩니다.

SAP HANA에 연결하는 애플리케이션이 VM에서 실행되는 경우 애플리케이션 VM은 동일한 가상 네트워크와 전용 애플리케이션 서브넷 내에 있어야 합니다. 또는 SAP HANA 연결이 주 데이터베이스가 아닌 경우 애플리케이션 VM을 다른 가상 네트워크에 배치할 수 있습니다. 워크로드별로 서브넷으로 분리하면 NSG(네트워크 보안 그룹)를 더 쉽게 사용하도록 설정하여 SAP HANA VM에만 적용할 수 있는 보안 규칙을 설정할 수 있습니다.

영역 중복 게이트웨이. 게이트웨이는 고유한 네트워크를 연결하여 온-프레미스 네트워크를 Azure 가상 머신으로 확장합니다. ExpressRoute를 사용하여 공용 인터넷을 통해 이동하지 않는 프라이빗 연결을 만드는 것이 좋습니다. 사이트 간 연결을 사용할 수도 있습니다. Azure ExpressRoute 또는 VPN 게이트웨이를 영역 간에 배포하여 영역 오류로부터 보호할 수 있습니다. 영역 중복 배포와 영역 중복 배포 간의 차이점을 이해하려면 영역 중복 가상 네트워크 게이트웨이를 참조하세요. 게이트웨이의 영역 배포에 사용되는 IP 주소는 표준 SKU여야 합니다.

네트워크 보안 그룹 (NSG). 가상 네트워크의 들어오고 나가는 네트워크 트래픽을 제한하려면 특정 서브넷에 할당되는 네트워크 보안 그룹을 만듭니다. DB 및 애플리케이션 서브넷은 워크로드별 NSG로 보호됩니다.

ASG(애플리케이션 보안 그룹). 애플리케이션을 중심으로 하는 워크로드를 기반으로 NSG 내에서 세분화된 네트워크 보안 정책을 정의하려면 명시적 IP 주소 대신 애플리케이션 보안 그룹을 사용합니다. VM의 네트워크 인터페이스를 이름별로 그룹화하고 네트워크의 신뢰할 수 있는 세그먼트에서 트래픽을 필터링하여 애플리케이션을 보호할 수 있습니다.

NIC(네트워크 인터페이스 카드). 네트워크 인터페이스 카드를 사용하면 가상 네트워크의 모든 가상 머신에서 통신할 수 있습니다. 기존 온-프레미스 SAP 배포는 머신당 여러 NIC를 구현하여 비즈니스 트래픽에서 관리 트래픽을 분리합니다.

Azure에서는 성능상의 이유로 여러 NIC를 사용할 필요가 없습니다. 여러 NIC는 VM의 동일한 네트워크 처리량 제한을 공유합니다. 그러나 조직에서 트래픽을 분리해야 하는 경우 VM당 여러 개의 NIC를 배포하고, 각 NIC를 서로 다른 서브넷에 연결할 수 있습니다. 그런 다음, 네트워크 보안 그룹을 사용하여 각 서브넷에 서로 다른 액세스 제어 정책을 적용할 수 있습니다.

Azure NIC는 여러 IP를 지원합니다. 이 지원은 설치에 가상 호스트 이름을 사용하는 SAP 권장 사례를 준수합니다. 전체 개요는 SAP 노트 962955를 참조하세요. (SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다.)

참고

SAP Note 2731110에 지정된 대로 애플리케이션과 SAP 애플리케이션 스택의 데이터베이스 계층 사이에 NVA(네트워크 가상 어플라이언스)를 배치하지 마세요. 이렇게 하면 상당한 데이터 패킷 처리 시간이 발생하며 애플리케이션 성능이 저하됩니다.

가상 머신

이 아키텍처는 VM(가상 머신)을 사용합니다. Azure는 가상 머신에서 최대 23.5TiB(테비바이트)의 단일 노드 스케일 업 메모리를 제공합니다. SAP 인증 및 지원되는 SAP HANA 하드웨어 디렉터리에는 SAP HANA 데이터베이스에 대해 인증된 가상 머신이 나열됩니다. 가상 머신 유형 및 처리량 메트릭(SAPS)에 대한 SAP 지원에 대한 자세한 내용은 SAP Note 1928533 - Microsoft Azure의 SAP 애플리케이션: 지원되는 제품 및 Azure VM 유형을 참조하세요. (이 노트와 기타 SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다.)

Microsoft와 SAP는 SAP HANA 워크로드에 대한 다양한 가상 머신 크기를 공동으로 인증합니다. 예를 들어 160GiB 이상의 RAM이 있는 Edsv4 또는 Edsv5 가상 머신에서 더 작은 배포를 실행할 수 있습니다. 가상 머신에서 최대 23TiB의 SAP HANA 메모리 크기를 지원하려면 Mv2 시리즈 가상 머신을 사용할 수 있습니다. M208 가상 머신 유형은 약 260,000개의 SAPS를 달성하고 M832ixs 가상 머신 유형은 약 795,900개의 SAPS를 달성합니다.

2세대(Gen2) 가상 머신. VM을 배포할 때 1세대 또는 2세대 VM을 사용할 수 있습니다. 2세대 VM은 1세대 VM에서 사용할 수 없는 주요 기능을 지원합니다. SAP HANA의 경우 Mv2 및 Mdsv2와 같은 일부 VM 제품군은 Gen2 VM으로만 지원되기 때문에 특히 중요합니다. 마찬가지로 일부 최신 VM에 대한 Azure 인증의 SAP는 Azure에서 둘 다 허용하더라도 전체 지원을 위해 Gen2만 필요할 수 있습니다. 자세한 내용은 SAP Note 1928533 - Microsoft의 SAP 애플리케이션: 지원되는 제품 및 Azure VM 유형을 참조하세요.

SAP HANA를 지원하는 다른 모든 VM은 Gen2만 또는 Gen1+2를 선택적으로 선택할 수 있으므로 모든 SAP VM을 Gen2로만 배포하는 것이 좋습니다. 이는 메모리 요구 사항이 낮은 VM에도 적용됩니다. 가장 작은 160GiB SAP HANA VM도 Gen2 VM으로 실행할 수 있으며 할당을 취소할 때 지역 및 구독에서 사용할 수 있는 가장 큰 VM으로 크기를 조정할 수 있습니다.

PPG(근접 배치 그룹). 네트워크 대기 시간을 최적화하기 위해 배치를 선호하는 근접 배치 그룹을 사용할 수 있습니다. 즉, 가상 머신이 동일한 데이터 센터에 있으므로 SAP HANA와 애플리케이션 VM 연결 간의 대기 시간을 최소화할 수 있습니다. SAP HANA 아키텍처 자체의 경우 PPG가 필요하지 않으며 애플리케이션 계층 VM으로 SAP HANA를 공동 배치하는 옵션일 뿐입니다. PPG의 잠재적 제한으로 인해 SAP 시스템의 PPG에 데이터베이스 AvSet을 추가하는 작업은 SAP 애플리케이션과 데이터베이스 트래픽 간의 대기 시간에 필요한 경우에만 드물게 수행해야 합니다. PPG의 사용 시나리오에 대한 자세한 내용은 연결된 설명서를 참조하세요. PPG는 워크로드를 단일 데이터 센터로 제한하므로 PPG는 여러 가용성 영역에 걸쳐 있지 않습니다.

구성 요소

고려 사항

이 섹션에서는 Azure에서 SAP HANA를 실행하기 위한 주요 고려 사항에 대해 설명합니다.

확장성

이 아키텍처는 한 인스턴스에서 최대 23TiB까지 확장할 수 있는 가상 머신에서 SAP HANA를 실행합니다.

워크로드가 최대 가상 머신 크기를 초과하는 경우 다중 노드 HANA 구성을 사용하는 것이 좋습니다. OLTP(온라인 트랜잭션 처리) 애플리케이션의 경우 총 스케일 아웃 메모리 용량은 최대 4 x 23TiB일 수 있습니다. OLAP(온라인 분석 처리) 애플리케이션의 경우 스케일 아웃 메모리 용량은 최대 16 x 7.6TiB일 수 있습니다. 예를 들어 공유 스토리지 볼륨에 Azure NetApp Files를 사용하여 Red Hat Enterprise Linux 또는 SUSE Linux Enterprise Server를 실행하는 가상 머신에서 대기가 있는 스케일 아웃 구성에서 SAP HANA를 배포할 수 있습니다.

스토리지

이 아키텍처는 가상 머신 또는 Azure NetApp Files의 스토리지에 Azure 관리 디스크를 사용합니다. 관리 디스크를 사용한 스토리지 배포에 대한 지침은 SAP HANA Azure 가상 머신 스토리지 구성 문서 내에 자세히 설명되어 있습니다. 관리 디스크 대신 Azure NetApp Files NFS 볼륨을 SAP HANA용 스토리지 솔루션으로 사용할 수 있습니다.

높은 IOPS(초당 입/출력 작업) 및 디스크 스토리지 처리량을 달성하려면 스토리지 볼륨 성능 최적화의 일반 사례를 Azure Storage 레이아웃에도 적용합니다. 예를 들어 여러 디스크를 LVM과 결합하여 스트라이프 디스크 볼륨을 만들면 IO 성능이 향상됩니다. 또한 Azure 디스크 캐싱은 필요한 IO 성능을 달성하는 데 중요한 역할을 합니다.

Azure Premium SSD v1에서 실행되는 SAP HANA 로그 디스크의 경우 프로덕션용 /hana/log를 보유하는 위치에서 다음 기술 중 하나를 사용합니다.

이러한 기술은 1ms 미만의 필요한 스토리지 대기 시간을 일관되게 충족하는 데 필요합니다.

Azure Premium SSD v2 는 SAP와 같은 성능에 중요한 워크로드를 위해 설계되었습니다. /hana/log 가 프리미엄 SSD v2에서 실행되는 경우 쓰기 가속기가 필요하지 않습니다. 이 스토리지 솔루션의 이점 및 현재 제한 사항에 대한 자세한 내용은 프리미엄 SSD v2 배포를 참조 하세요.

SAP HANA 성능 요구 사항에 대한 자세한 내용은 SAP Note 1943937 - 하드웨어 구성 검사 도구를 참조하세요.

  • 비프로덕션 시스템을 위한 비용에 민감한 스토리지 디자인. 모든 상황에서 최대 스토리지 성능이 필요하지 않은 SAP HANA 환경의 경우 비용에 최적화된 스토리지 아키텍처를 사용할 수 있습니다. 이러한 스토리지 최적화 선택은 거의 사용되지 않는 프로덕션 시스템 또는 일부 비프로덕션 SAP HANA 환경에 적용할 수 있습니다. 비용 최적화 스토리지 옵션은 프로덕션 환경에 사용되는 프리미엄 또는 Ultra SSD 대신 표준 SSD의 조합을 사용합니다. 또한 /hana/data 및 /hana/log 파일 시스템을 단일 디스크 집합에 결합합니다. 지침 및 모범 사례는 대부분의 VM 크기에 사용할 수 있습니다. SAP HANA용 Azure NetApp Files를 사용하는 경우 크기가 축소된 볼륨을 사용하여 동일한 목표를 달성할 수 있습니다.

  • 스케일 업 시 스토리지 크기 조정 비즈니스 요구 사항이 변경되거나 데이터베이스 크기가 증가하여 가상 머신의 크기를 조정하면 스토리지 구성이 변경될 수 있습니다. Azure는 서비스를 중단하지 않고 온라인 디스크 확장을 지원합니다. SAP HANA에 사용되는 스트라이프 디스크 설정을 사용하면 크기 조정 작업이 볼륨 그룹의 모든 디스크와 동일하게 수행되어야 합니다. 볼륨 그룹에 디스크를 더 추가하면 스트라이프 데이터의 불균형이 발생할 수 있습니다. 스토리지 구성에 디스크를 더 추가하는 경우 새 디스크에 새 스토리지 볼륨을 만드는 것이 훨씬 좋습니다. 다음으로 가동 중지 시간 동안 콘텐츠를 복사하고 탑재 지점을 수정합니다. 마지막으로, 이전 볼륨 그룹 및 기본 디스크를 카드.

  • Azure NetApp Files 애플리케이션 볼륨 그룹입니다. Azure NetApp Files NFS 볼륨에 포함된 SAP HANA 파일이 있는 배포의 경우 애플리케이션 볼륨 그룹을 사용하면 모범 사례에 따라 모든 볼륨을 배포할 수 있습니다. 또한 이 프로세스는 SAP HANA 데이터베이스에 대한 최적의 성능을 보장합니다. 이 프로세스를 진행하는 방법에 대한 세부 정보를 확인할 수 있습니다 . 수동 개입이 필요합니다. 만들기에 약간의 시간을 허용합니다.

고가용성

앞의 아키텍처는 SAP HANA가 둘 이상의 가상 머신에 포함된 고가용성 배포를 보여 줍니다. 다음 구성 요소가 사용됩니다.

부하 분산 장치.Azure Load Balancer 는 SAP HANA 가상 머신에 트래픽을 분산하는 데 사용됩니다. SAP의 영역 배포에 Azure Load Balancer를 통합하는 경우 표준 SKU 부하 분산 장치를 선택해야 합니다. 기본 SKU 분산 장치는 영역 중복을 지원하지 않습니다. 이 아키텍처에서 Load Balancer는 SAP HANA의 가상 IP 주소 역할을 합니다. 네트워크 트래픽은 주 데이터베이스 인스턴스가 실행되는 활성 VM으로 전송됩니다. SAP HANA 활성/읽기 사용 아키텍처(SLES/RHEL)를 사용할 수 있습니다. 여기서 부하 분산 장치에서 주소가 지정된 두 번째 가상 IP를 사용하여 읽기 강도가 강한 워크로드를 위해 다른 VM의 보조 SAP HANA 인스턴스로 네트워크 트래픽을 전송합니다.

표준 Load Balancer 기본적으로 보안 계층을 제공합니다. 표준 Load Balancer 뒤에 있는 가상 머신에는 아웃바운드 인터넷 연결이 없습니다. 이러한 가상 머신에서 아웃바운드 인터넷을 사용하도록 설정하려면 표준 Load Balancer 구성을 업데이트해야 합니다. 또한 Azure NAT 게이트웨이를 사용하여 아웃바운드 연결을 가져올 수도 있습니다.

SAP HANA 데이터베이스 클러스터의 경우 부동 IP라고도 하는 DSR(Direct Server Return)을 사용하도록 설정해야 합니다. 이 기능을 사용하면 서버가 부하 분산 장치 프런트 엔드의 IP 주소에 응답할 수 있습니다. 이 직접 연결은 부하 분산 장치가 데이터 전송 경로에서 병목 상태가 되지 않도록 합니다.

배포 옵션. Azure에서 SAP 워크로드 배포는 SAP 애플리케이션의 가용성 및 복원력 요구 사항에 따라 지역 또는 영역이 될 수 있습니다. Azure는 리소스의 가용성을 향상시키기 위해 유연한 오케스트레이션(FD=1), 가용성 영역 및 가용성 집합을 사용하는 Virtual Machine Scale Sets와 같은 다양한 배포 옵션을 제공합니다. 여러 Azure 지역(영역 간, 단일 영역 내 또는 영역이 없는 지역 포함)에서 사용 가능한 배포 옵션 및 해당 적용 가능성을 포괄적으로 이해하려면 SAP NetWeaver에 대한 고가용성 아키텍처 및 시나리오를 참조하세요.

SAP HANA 고가용성을 위해 SAP HANA는 둘 이상의 Linux 가상 머신에서 실행됩니다. SAP HSR(HANA 시스템 복제)은 주 및 보조(복제본) SAP HANA 시스템 간에 데이터를 복제하는 데 사용됩니다. HSR은 지역 간 또는 영역 간 재해 복구에도 사용됩니다. 가상 머신 간의 통신 대기 시간에 따라 지역 내에서 동기 복제를 사용할 수 있습니다. 재해 복구를 위한 지역 간 HSR은 대부분의 경우 비동기 방식으로 실행됩니다.

Linux Pacemaker 클러스터의 경우 사용할 클러스터 펜싱 메커니즘을 결정해야 합니다. 클러스터 펜싱은 실패한 VM을 클러스터에서 격리하고 다시 시작하는 프로세스입니다. RHEL(RedHat Enterprise Linux)의 경우 Azure에서 Pacemaker에 지원되는 유일한 펜싱 메커니즘은 Azure Fence 에이전트입니다. SLES(SUSE Linux Enterprise Server)의 경우 Azure 펜스 에이전트 또는 SBD(STONITH 블록 디바이스)를 사용할 수 있습니다. 각 솔루션의 장애 조치(failover) 시간을 비교하고, 차이가 있는 경우 RTO(복구 시간 목표)에 대한 비즈니스 요구 사항에 따라 솔루션을 선택합니다.

Azure 펜스 에이전트. 이 펜싱 메서드는 Azure ARM API를 사용하며 Pacemaker는 클러스터에 있는 두 SAP HANA VM의 상태 대해 ARM API를 쿼리합니다. 한 VM이 실패하는 경우(예: OS 응답하지 않거나 VM 충돌) 클러스터 관리자는 ARM API를 다시 사용하여 VM을 다시 시작하고 필요한 경우 SAP HANA 데이터베이스를 다른 활성 노드로 장애 조치합니다. 이를 위해 VM을 쿼리하고 다시 시작하는 사용자 지정 역할이 있는 SPN(서비스 이름 보안 주체)을 사용하여 ARM API에 대해 권한을 부여합니다. 다른 인프라는 필요하지 않으며, Azure 펜스 에이전트를 사용하는 경우 아키텍처 드로잉의 SBD VM은 배포되지 않습니다.

Sbd. STONITH SBD(블록 디바이스)는 클러스터 관리자가 블록 디바이스(원시, 파일 시스템 없음)로 액세스하는 디스크를 사용합니다. 이 디스크 또는 여러 디스크가 투표로 작동합니다. SAP HANA를 실행하는 두 개의 클러스터 노드는 각각 SDB 디스크에 액세스하고 상태에 대한 작은 정보를 주기적으로 읽고 씁니다. 따라서 각 클러스터 노드는 VM 간의 네트워킹에만 의존하지 않고 다른 노드에 대한 상태를 알고 있습니다.

가용성 집합 또는 가용성 영역 설정에 세 개의 작은 VM이 배포되는 것이 좋습니다. 각 VM은 두 개의 SAP HANA 클러스터 노드에서 액세스하는 블록 디바이스로 디스크의 작은 부분을 내보냅니다. 세 개의 SBD VM은 SBD VM에 대해 계획되거나 계획되지 않은 가동 중지 시간이 발생하는 경우 충분한 투표 멤버를 사용할 수 있도록 합니다.

또는 SBD VM을 사용하는 대신 Azure 공유 디스크를 사용할 수 있습니다. 그러면 SAP HANA 클러스터 노드가 단일 공유 디스크에 액세스합니다. Azure 지역에서 ZRS를 사용할 수 있는 경우 공유 디스크는 로컬(LRS) 또는 영역별(ZRS) 중복일 수 있습니다.

재해 복구

다음 아키텍처는 재해 복구를 제공하는 Azure의 프로덕션 HANA 환경을 보여 줍니다. 아키텍처는 가용성 영역을 통합합니다.

재해 복구를 사용하는 아키텍처를 보여 주는 다이어그램

DR 전략 및 구현 세부 정보는 SAP 애플리케이션에 대한 SAP 워크로드 및 재해 복구 지침에 대한 재해 복구 개요 및 인프라 지침을 참조하세요.

참고 항목

한 지역의 많은 Azure 고객에게 큰 장애 조치(failover) 이벤트를 발생시키는 지역 재해가 있는 경우 대상 지역의 리소스 용량 이 보장되지 않습니다. 모든 Azure 서비스와 마찬가지로 Azure Site Recovery는 계속해서 기능과 기능을 추가합니다. Azure 간 복제에 대한 최신 정보는 지원 매트릭스를 참조하세요.

HSR은 로컬 2노드 고가용성 구현 외에도 다중 계층 및 다중 대상 복제본(replica)tion을 지원합니다. 따라서 HSR은 영역 간 및 지역 간 복제본(replica). 다중 대상 복제는 SAP HANA 2.0 SPS 03 이상에서 사용할 수 있습니다.

대상 지역의 리소스 용량을 확인해야 합니다.

Azure NetApp Files. 옵션으로 Azure NetApp Files 를 사용하여 SAP HANA 데이터 및 로그 파일에 대한 확장 가능하고 고성능 스토리지 솔루션을 제공할 수 있습니다. Azure NetApp Files는 빠른 백업, 복구 및 로컬 복제를 위한 스냅샷을 지원합니다. 지역 간 콘텐츠 복제의 경우 Azure NetApp Files 지역 간 복제를 사용하여 두 지역 간에 스냅샷 데이터를 복제할 수 있습니다. 지역 간 복제에 대한 세부 정보와 Azure NetApp Files를 사용한 재해 복구에 대한 모든 측면을 설명하는 백서를 사용할 수 있습니다.

Backup

SAP HANA 데이터는 다양한 방법으로 백업할 수 있습니다. Azure로 마이그레이션한 후 이미 있는 기존 파트너 백업 솔루션을 계속 사용할 수 있습니다. Azure는 SAP HANA 파일 수준 백업과 Backint 인터페이스를 통한 SAP HANA용 Azure Backup이라는 두 가지 네이티브 방식을 제공합니다.

SAP HANA 파일 수준 백업의 경우 hdbsql 또는 SAP HANA Studio와 같은 원하는 도구를 사용하고 로컬 디스크 볼륨에 백업 파일을 저장할 수 있습니다. 이 백업 볼륨의 일반적인 탑재 지점은 /hana/backup입니다. 백업 정책은 볼륨의 데이터 보존 기간을 정의합니다. 백업을 수행하는 즉시 예약된 작업은 백업 파일을 Azure Blob Storage에 복사하여 안전하게 보관해야 합니다. 로컬 백업 파일은 신속한 복구를 위해 보관됩니다.

Azure Backup은 가상 머신에서 실행되는 워크로드를 위한 간단한 엔터프라이즈급 솔루션을 제공합니다. SAP HANA용 Azure Backup은 SAP HANA 백업 카탈로그와 전체 통합을 제공하고 데이터베이스 일관성, 전체 또는 특정 시점 복구를 보장합니다. Azure Backup은 SAP에서 BackInt 인증을 받았습니다. Azure Backup FAQ 및 지원 매트릭스도 참조하세요.

Azure NetApp Files는 스냅샷 기반 백업을 지원합니다. 애플리케이션 일관성 스냅샷을 위해 SAP HANA와 통합하는 것은 Azure 애플리케이션 일관성 스냅샷 도구(AzAcSnap)를 통해 이루어집니다. 만든 스냅샷은 시스템 복원 또는 SAP HANA 데이터베이스 복사를 위해 새 볼륨으로 복원하는 데 사용할 수 있습니다. 만든 스냅샷은 다른 NFS 볼륨에 저장된 SAP HANA 로그를 통해 복원 지점 역할을 하는 재해 복구에 사용할 수 있습니다.

모니터링

Azure에서 워크로드를 모니터링하기 위해 Azure Monitor를 사용하면 클라우드 및 온-프레미스 환경에서 원격 분석을 포괄적으로 수집, 분석 및 수행할 수 있습니다.

SAP HANA 및 기타 주요 데이터베이스 솔루션에서 실행되는 SAP 애플리케이션의 경우 SAP용 Azure Monitor가 SAP 서비스의 가용성 및 성능을 관리하는 데 어떻게 도움이 되는지 알아보려면 SAP용 Azure Monitor 솔루션을 참조하세요.

보안

SAP 환경의 기밀성, 무결성 및 가용성을 보호하기 위해 많은 보안 조치가 사용됩니다. 예를 들어 사용자 액세스를 보호하기 위해 SAP에는 자체적인 SAP 애플리케이션 및 데이터베이스 내에서 역할 기반 액세스 및 권한 부여를 제어하는 자체 UME(사용자 관리 엔진)가 있습니다. 자세한 내용은 SAP HANA 보안 - 개요를 참조하세요.

미사용 데이터의 경우 다음과 같이 다양한 암호화 기능이 보안을 제공합니다.

  • SAP HANA 네이티브 암호화 기술과 함께 고객 관리형 키를 지원하는 파트너의 암호화 솔루션을 사용하는 것이 좋습니다.

  • 가상 머신 디스크를 암호화하려면 디스크 암호화 개요에 설명된 기능을 사용하면 됩니다.

  • SAP 데이터베이스 서버: DBMS 공급자(예: SAP HANA 네이티브 암호화 기술)에서 제공하는 투명한 데이터 암호화 사용하여 데이터 및 로그 파일을 보호하고 백업도 암호화되도록 합니다.

  • Azure 물리적 스토리지의 데이터(서버 쪽 암호화)는 Azure 관리형 키를 사용하여 미사용 시 자동으로 암호화됩니다. Azure 관리형 키 대신 CMK(고객 관리형 키)를 선택할 수도 있습니다.

  • 특정 Linux 배포판, 버전 및 이미지에서 Azure Disk Encryption 지원에 대한 자세한 내용은 Linux VM용 Azure Disk Encryption을 참조 하세요.

참고 항목

SAP HANA 네이티브 암호화 기술을 동일한 스토리지 볼륨의 Azure Disk Encryption 또는 호스트 기반 암호화와 결합하지 마세요. 또한 Linux 가상 머신용 운영 체제 부팅 디스크는 Azure Disk Encryption을 지원하지 않습니다. 대신 SAP HANA 네이티브 암호화를 사용하는 경우 자동으로 사용하도록 설정되는 서버 쪽 암호화와 결합합니다. 고객 관리형 키의 사용은 스토리지 처리량에 영향을 줄 수 있습니다.

네트워크 보안을 위해 다음과 같이 NSG(네트워크 보안 그룹) 및 Azure Firewall 또는 네트워크 가상 어플라이언스를 사용합니다.

  • NSG를 사용하여 서브넷과 애플리케이션/데이터베이스 계층 간의 트래픽을 보호하고 제어합니다. 서브넷에만 NSG를 적용합니다. NIC와 서브넷 모두에 적용된 NSG는 문제 해결 중에 문제가 발생하는 경우가 많으며, 거의 사용하지 않아야 합니다.

  • Azure Firewall 또는 Azure 네트워크 가상 어플라이언스를 사용하여 허브 가상 네트워크에서 SAP 애플리케이션이 있는 스포크 가상 네트워크로의 트래픽 라우팅을 검사 및 제어하고 아웃바운드 인터넷 연결도 제어합니다.

사용자 및 권한 부여의 경우 다음과 같이 RBAC(역할 기반 액세스 제어) 및 리소스 잠금을 구현합니다.

  • AZURE에서 SAP 솔루션을 호스트하는 IaaS 수준 리소스에서 관리 권한을 할당하기 위해 RBAC를 사용하여 최소 권한 원칙을 따릅니다. RBAC의 기본 목적은 사용자/그룹에 대한 업무를 분리하고 제어하는 것입니다. RBAC는 사용자가 작업을 수행할 수 있도록 하는 데 필요한 리소스에 대한 액세스 권한만 부여하도록 설계되었습니다.

  • 리소스 잠금을 사용하여 우발적이거나 악의적인 변경을 방지합니다. 리소스 잠금은 관리자가 SAP 솔루션이 있는 중요한 Azure 리소스를 삭제하거나 수정하지 못하게 하는 데 도움이 됩니다.

더 많은 보안 권장 사항은 Microsoft 및 SAP 문서에서 찾을 수 있습니다.

커뮤니티

커뮤니티는 질문에 대답하고 성공적인 배포를 설정하는 데 도움을 줄 수 있습니다. 다음 커뮤니티를 고려합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계

구성 요소 기술에 대해 자세히 알아보세요.

관련 아키텍처 살펴보기: