다음을 통해 공유

Azure 기반 Linux의 SAP S/4HANA

이 가이드에서는 Azure에서 DR(재해 복구)을 지원하는 HA(고가용성) 환경에서 HANA에서 S/4HANA 및 Suite를 실행하기 위한 검증된 사례 집합을 제공합니다. Fiori 정보는 S/4HANA 애플리케이션에만 적용됩니다.

건축학

Azure 가용성 집합의 Linux 가상 머신용 SAP S/4HANA를 보여 주는 아키텍처 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

비고

이 아키텍처를 배포하려면 SAP 제품 및 기타 타사 기술에 필요한 라이선스가 있는지 확인합니다.

이 가이드에서는 일반적인 프로덕션 시스템에 대해 설명합니다. 이 아키텍처는 다양한 VM(가상 머신) 크기를 사용합니다. 조직의 요구 사항을 수용하기 위해 크기를 조정하거나 이 구성을 단일 VM으로 줄일 수 있습니다.

이 가이드에서는 아키텍처 원칙을 보여 주기 위해 네트워크 레이아웃이 간소화되었습니다. 전체 엔터프라이즈 네트워크를 나타내지 않습니다.

아키텍처에서 사용하는 구성 요소는 다음과 같습니다. 일부 공유 서비스는 선택 사항입니다.

Azure Virtual Network. Virtual Network 서비스는 보안 강화를 통해 Azure 리소스를 서로 연결합니다. 이 아키텍처에서 가상 네트워크는 hub-spoke 토폴로지의 허브에 배포된 게이트웨이를 통해 온-프레미스 환경에 연결합니다. 스포크는 SAP 애플리케이션 및 데이터베이스 계층에 사용되는 가상 네트워크입니다.

가상 네트워크 피어링. 이 아키텍처는 피어링된 여러 가상 네트워크를 사용합니다. 이 토폴로지에서는 Azure에 배포된 서비스에 대한 네트워크 구분 및 격리를 제공합니다. 피어링이 Microsoft 백본 네트워크를 통해 네트워크를 투명하게 연결하며 단일 지역 내에서 구현되는 경우 성능 저하가 발생하지 않습니다. 애플리케이션 계층(SAP NetWeaver) 및 데이터베이스 계층을 비롯한 각 계층과 점프 상자 및 Windows Server Active Directory와 같은 공유 구성 요소에 대해 별도의 서브넷이 사용됩니다.

가상 머신들. 이 아키텍처는 다음과 같은 방법으로 애플리케이션 계층 및 데이터베이스 계층에 대한 그룹으로 Linux를 실행하는 VM을 구성합니다.

  • 애플리케이션 계층 이 아키텍처 계층에는 Fiori 프런트 엔드 서버 풀, SAP Web Dispatcher 풀, 애플리케이션 서버 풀 및 SAP Central Services 클러스터가 포함됩니다. Linux VM에서 실행되는 Azure의 Central Services HA의 경우 Azure Files의 NFS(네트워크 파일 시스템) 파일 공유, Azure NetApp Files, 클러스터된 NFS 서버 또는 Linux용 SIOS Protection Suite와 같은 고가용성 네트워크 파일 공유 서비스가 필요합니다. RHEL(Red Hat Enterprise Linux)에서 Central Services 클러스터에 대해 고가용성 파일 공유를 설정하려면 RHEL을 실행하는 Azure VM에서 GlusterFS를 구성할 수 있습니다. SLES(SUSE Linux Enterprise Server) 15 SP1 이상 버전 또는 SAP 애플리케이션용 SLES에서 Pacemaker 클러스터의 Azure 공유 디스크 를 펜싱 디바이스로 사용하여 HA를 달성할 수 있습니다.

  • SAP HANA 데이터베이스 계층은 클러스터에서 둘 이상의 Linux VM을 사용하여 강화 배포에서 HA를 달성합니다. HSR(HANA 시스템 복제)을 사용하여 주 및 보조 HANA 시스템 간에 콘텐츠를 복제합니다. Linux 클러스터링을 사용하여 시스템 장애를 감지하고 자동 장애 조치를 용이하게 합니다. 분할된 클러스터를 방지하기 위해 실패한 시스템을 격리하거나 종료할 수 있도록 스토리지 기반 또는 클라우드 기반 펜싱 메커니즘을 사용해야 합니다. HANA 스케일 아웃 배포에서는 다음 옵션 중 하나를 사용하여 데이터베이스 HA를 달성할 수 있습니다.

    • Linux 클러스터링 구성 요소 없이 Azure NetApp Files를 사용하여 HANA 대기 노드를 구성합니다.

    • Azure Premium Storage를 사용하여 대기 노드 없이 스케일 아웃합니다. 장애 조치(failover)를 위해 Linux 클러스터링을 사용합니다.

  • Azure Bastion을 사용합니다. 이 서비스를 사용하면 브라우저와 Azure Portal을 사용하거나 로컬 컴퓨터에 설치된 네이티브 SSH(Secure Shell) 또는 RDP(원격 데스크톱 프로토콜) 클라이언트를 사용하여 VM에 연결할 수 있습니다. RDP 및 SSH만 관리에 사용되는 경우 Azure Bastion을 사용하는 것이 좋습니다. SQL Server Management Studio 또는 SAP 프런트 엔드와 같은 다른 관리 도구를 사용하는 경우 기존의 자체 배포 점프 상자를 사용합니다.

프라이빗 DNS 서비스입니다.Azure 프라이빗 DNS 가상 네트워크에 대한 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다.

부하 분산 장치. 가용성을 높이기 위해 SAP 애플리케이션 계층 서브넷의 VM에 트래픽을 분산하려면 Azure 표준 Load Balancer를 사용합니다. 표준 Load Balancer는 기본적으로 보안 계층을 제공합니다. 표준 Load Balancer 뒤에 있는 VM에는 아웃바운드 인터넷 연결이 없습니다. VM에서 아웃바운드 인터넷을 사용하도록 설정하려면 표준 Load Balancer 구성을 업데이트해야 합니다. Azure NAT Gateway를 사용하여 아웃바운드 연결을 가져올 수도 있습니다. SAP 웹 기반 애플리케이션 HA의 경우 기본 제공 SAP Web Dispatcher 또는 상업적으로 사용 가능한 다른 부하 분산 장치를 사용합니다. 선택 기준은 다음과 같습니다.

  • HTTP 또는 SAP GUI(그래픽 사용자 인터페이스) 트래픽과 같은 트래픽 유형입니다.
  • SSL(Secure Sockets Layer) 종료와 같이 필요한 네트워크 기능입니다.

표준 Load Balancer는 여러 프런트 엔드 가상 IP 주소를 지원합니다. 이 지원은 다음 구성 요소를 포함하는 클러스터 구현에 적합합니다.

  • ABAP(Advanced Business Application Programming) ASCS(SAP Central Services)
  • 복제 서버를 큐에 추가하기

이러한 두 구성 요소는 부하 분산 장치를 공유하여 솔루션을 단순화할 수 있습니다.

표준 Load Balancer는 다중 시스템 식별자(다중 SID) SAP 클러스터도 지원합니다. 이 기능을 사용하면 SLES 또는 RHEL 의 여러 SAP 시스템이 일반적인 HA 인프라를 공유하여 비용을 절감할 수 있습니다. 비용 절감을 평가하고 하나의 클러스터에 너무 많은 시스템을 배치하지 않는 것이 좋습니다. Azure는 클러스터당 최대 5개의 SID를 지원합니다.

애플리케이션 게이트웨이 Azure Application Gateway는 웹 애플리케이션에 대한 트래픽을 관리하는 데 사용할 수 있는 웹 트래픽 부하 분산 장치입니다. 기존의 부하 분산 장치는 전송 제어 프로토콜 및 사용자 데이터그램 프로토콜을 사용하여 OSI(Open Systems Interconnection) 계층 4라고 하는 전송 계층에서 작동합니다. 원본 IP 주소와 포트를 기반으로 트래픽을 대상 IP 주소와 포트로 라우팅합니다. Application Gateway는 균일한 리소스 식별자 경로 또는 호스트 헤더와 같은 HTTP 요청의 추가 특성에 따라 라우팅 결정을 내릴 수 있습니다. 이러한 유형의 라우팅을 애플리케이션 계층 또는 OSI 계층 7 부하 분산이라고 합니다. S/4HANA는 Fiori를 통해 웹 애플리케이션 서비스를 제공합니다. Application Gateway를 사용하여 웹앱으로 구성된 이 Fiori 프런트 엔드의 부하를 분산할 수 있습니다. 공용 IP 주소를 사용하는 경우 표준 IP 주소 SKU를 사용하는지 확인합니다. 기본 IP 주소 SKU는 2025년 9월 30일에 사용 중단될 예정이므로 사용하지 마세요.

게이트웨이 게이트웨이는 고유한 네트워크를 연결하고 온-프레미스 네트워크를 Azure 가상 네트워크로 확장합니다. Azure ExpressRoute 는 공용 인터넷을 통해 이동하지 않는 프라이빗 연결을 만드는 데 권장되는 Azure 서비스입니다. 사이트 간 연결을 사용할 수도 있습니다. 대기 시간을 줄이려면 ExpressRoute Global Reach 또는 ExpressRoute FastPath를 사용합니다.

영역 중복 게이트웨이. ExpressRoute 또는 VPN(가상 사설망) 게이트웨이를 영역 간에 배포하여 영역 오류로부터 보호할 수 있습니다. 이 아키텍처는 동일한 가용성 영역을 기반으로 하는 영역 기반 배포 대신 신뢰성을 위해 지역 중복 가상 네트워크 게이트웨이를 사용합니다.

근접 배치 그룹. 이 논리 그룹은 가용성 집합 또는 가상 머신 확장 집합에 배포된 VM에 제약 조건을 적용합니다. 근접 배치 그룹은 VM이 동일한 데이터 센터에 배포되도록 하여 공동 배치를 적용하는 데 도움이 됩니다. 이 구성은 애플리케이션 대기 시간을 최소화하기 위해 리소스 간의 물리적 거리를 줄입니다.

비고

업데이트된 구성 전략은 SAP 애플리케이션을 사용하여 네트워크 대기 시간을 최소화하는 구성 옵션을 참조하세요. 이 문서에서는 네트워크 대기 시간을 위해 SAP 시스템을 최적화할 때 배포 유연성의 잠재적인 장차를 설명합니다.

NSG(네트워크 보안 그룹). 가상 네트워크에서 들어오고 나가는 서브넷 내 트래픽을 제한하려면 NSG를 만들 수 있습니다.

애플리케이션 보안 그룹. 워크로드를 기반으로 하며 애플리케이션에 중앙화되어 세분화된 네트워크 보안 정책을 정의하기 위해 명시적 IP 주소 대신 애플리케이션 보안 그룹을 사용할 수 있습니다. 네트워크의 신뢰할 수 있는 세그먼트에서 트래픽을 필터링하여 이름 및 보안 애플리케이션을 기준으로 VM을 그룹화할 수 있습니다.

Azure Storage. 스토리지는 가상 하드 디스크의 형태로 VM에 대한 데이터 지속성을 제공합니다. Azure 관리 디스크를 사용하는 것이 좋습니다.

권장 사항

이 아키텍처는 소규모 프로덕션 수준의 배포를 설명합니다. 배포는 비즈니스 요구 사항에 따라 다르므로 이러한 권장 사항을 시작점으로 고려합니다.

가상 머신들

애플리케이션 서버 풀 및 클러스터에서 요구 사항에 따라 VM 수를 조정합니다. VM에서 SAP NetWeaver를 실행하는 방법에 대한 자세한 내용은 Azure Virtual Machines 계획 및 구현 가이드를 참조하세요. 이 가이드는 SAP S/4HANA 배포에도 적용됩니다.

Azure VM 유형에 대한 SAP 지원 및 처리량 메트릭에 대한 자세한 내용은 SAP 참고 1928533 참조하세요. SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다. HANA 데이터베이스에 대한 인증된 Azure VM 목록은 SAP 인증 및 지원되는 SAP HANA 하드웨어 디렉터리를 참조하세요.

SAP Web Dispatcher

Web Dispatcher 구성 요소는 SAP 애플리케이션 서버 간에 SAP 트래픽 부하 분산에 사용됩니다. SAP Web Dispatcher의 HA를 달성하기 위해 Azure Load Balancer는 장애 조치(failover) 클러스터 또는 병렬 Web Dispatcher 설정을 구현합니다. 인터넷 연결 통신의 경우 경계 네트워크의 독립 실행형 솔루션은 보안 요구 사항을 해결하는 데 권장되는 아키텍처입니다. ASCS의 포함된 웹 디스패처 는 고급 구성입니다. 이 구성을 사용하는 경우 ASCS의 추가 워크로드로 인해 적절한 크기 조정을 고려합니다.

Fiori FES(프런트 엔드 서버)

이 아키텍처는 여러 요구 사항을 충족하며 포함된 Fiori FES 모델을 사용한다고 가정합니다. 모든 기술 구성 요소는 S/4 시스템에 직접 설치되므로 각 S/4 시스템에는 자체 Fiori 실행 패드가 있습니다. S/4 시스템은 이 배포 모델에 대한 HA 구성을 관리합니다. 이 방법을 사용하면 추가 클러스터링 또는 VM이 필요하지 않습니다. 이러한 이유로 아키텍처 다이어그램에는 FES 구성 요소가 포함되지 않습니다.

배포 옵션에 대한 자세한 내용은 SAP Fiori 배포 옵션 및 시스템 환경 권장 사항을 참조하세요. 단순성과 성능을 위해 Fiori 기술 구성 요소와 S/4 애플리케이션 간의 소프트웨어 릴리스가 긴밀하게 결합되어 있습니다. 이 설정을 통해 허브 배포는 몇 가지 특정 사용 사례에만 적합합니다.

FES 허브 배포를 사용하는 경우 FES는 클래식 SAP NetWeaver ABAP 스택에 대한 추가 기능 구성 요소입니다. 클러스터형 또는 다중 호스트 기능이 있는 3계층 ABAP 애플리케이션 스택을 보호하는 것과 동일한 방식으로 HA를 설정합니다. 대기 서버 데이터베이스 계층, 공유 스토리지용 HA NFS가 있는 클러스터형 ASCS 계층 및 두 개 이상의 애플리케이션 서버를 사용합니다. 트래픽은 클러스터형이거나 병렬일 수 있는 한 쌍의 Web Dispatcher 인스턴스를 통해 부하가 분산됩니다. 인터넷 연결 Fiori 앱의 경우 경계 네트워크에서 FES 허브 배포를 수행하는 것이 좋습니다. Application Gateway에서 Azure Web Application Firewall을 중요한 구성 요소로 사용하여 위협을 편향합니다. Microsoft Entra ID를 보안 어설션 마크업 언어와 함께 사용자 인증에 사용하고, SAP Fiori에 SSO(Single Sign-On)를 사용합니다.

인터넷과 두 가상 네트워크 간의 데이터 흐름을 보여 주는 아키텍처 다이어그램으로, 하나는 SAP Fiori를 사용하고 다른 하나는 SAP S/4HANA를 사용합니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

자세한 내용은 Azure의 SAP에 대한 인바운드 및 아웃바운드 인터넷 연결을 참조하세요.

애플리케이션 서버 풀

ABAP 애플리케이션 서버에 대한 로그온 그룹을 관리하려면 다음 트랜잭션 코드를 사용합니다.

  • SMLG: 로그온 사용자 부하를 분산합니다.
  • SM61: 일괄 처리 서버 그룹을 관리합니다.
  • RZ12: RFC(원격 함수 호출) 그룹을 관리합니다.

이러한 트랜잭션은 중앙 서비스 메시지 서버의 부하 분산 기능을 사용하여 SAP GUI 및 RFC 트래픽을 관리하는 SAP 애플리케이션 서버 풀에 들어오는 세션 및 워크로드를 분산합니다.

SAP Central Services 클러스터

SAP Central Services에는 메시지 서버의 단일 인스턴스와 큐에 넣기 복제 서비스가 포함됩니다. 애플리케이션 서버의 작업 프로세스와 달리 이러한 구성 요소는 SAP 애플리케이션 스택의 단일 실패 지점입니다. Azure 단일 인스턴스 VM 가용성 SLA(서비스 수준 계약)가 요구 사항을 충족하는 경우 Central Services를 단일 VM에 배포할 수 있습니다. SLA에 더 높은 가용성이 필요한 경우 HA 클러스터에 이러한 서비스를 배포해야 합니다. 자세한 내용은 애플리케이션 서버 계층의 Central Services를 참조하세요.

네트워킹

이 아키텍처는 허브 가상 네트워크가 온-프레미스 네트워크에 대한 연결의 중심 지점 역할을 하는 허브-스포크 토폴로지를 사용합니다. 스포크는 허브와 피어링하는 가상 네트워크입니다. 스포크를 사용하여 워크로드를 격리할 수 있습니다. 트래픽은 게이트웨이 연결을 통해 온-프레미스 데이터 센터와 허브 간에 흐릅니다.

네트워크 인터페이스 카드

기존의 온-프레미스 SAP 배포는 컴퓨터당 여러 NIC(네트워크 인터페이스 카드)를 구현하여 비즈니스 트래픽과 관리 트래픽을 분리합니다. Azure에서 가상 네트워크는 단일 네트워크 패브릭을 통해 모든 트래픽을 라우팅하는 소프트웨어 정의 네트워크입니다. 따라서 성능상의 이유로 여러 NIC가 필요하지 않습니다. 조직에서 트래픽을 분리해야 하는 경우 각 VM에 대해 여러 NIC를 배포하고, 각 NIC를 다른 서브넷에 연결한 다음, NSG를 사용하여 다른 액세스 제어 정책을 적용할 수 있습니다.

Azure NIC는 여러 IP 주소를 지원합니다. 이 지원은 SAP 노트 962955에서 권장하는 설치 시 가상 호스트 이름을 사용하는 관행과 일치합니다.

서브넷 및 NSG

이 아키텍처는 가상 네트워크 주소 공간을 서브넷으로 나눕니다. 서브넷에 대한 액세스 정책을 정의하는 NSG와 각 서브넷을 연결할 수 있습니다. 별도의 서브넷에 애플리케이션 서버를 배치합니다. 이 방법을 사용하면 개별 서버 대신 서브넷 보안 정책을 관리하여 애플리케이션 서버를 보다 쉽게 보호할 수 있습니다.

NSG를 서브넷과 연결하는 경우 NSG는 서브넷 내의 모든 서버에 적용되며 서버에 대한 세분화된 제어를 제공합니다. Azure Portal, Azure PowerShell 또는 AzureCLI를 사용하여 NSG를 설정합니다.

ExpressRoute Global Reach

네트워크 환경에 둘 이상의 ExpressRoute 회로가 포함된 경우 ExpressRoute Global Reach 를 사용하면 네트워크 홉을 줄이고 대기 시간을 줄일 수 있습니다. 이 기술은 두 개의 ExpressRoute 라우팅 도메인을 연결하기 위해 둘 이상의 ExpressRoute 회로 간에 설정된 경계 게이트웨이 프로토콜 경로 피어링입니다. Global Reach는 네트워크 트래픽이 둘 이상의 ExpressRoute 회로를 트래버스할 때 대기 시간을 줄입니다. ExpressRoute 회로의 프라이빗 피어링에만 사용할 수 있습니다.

Global Reach는 네트워크 액세스 제어 목록 또는 기타 특성에 대한 변경을 지원하지 않습니다. 온-프레미스 또는 Azure에서 ExpressRoute 회로에서 학습된 모든 경로는 회로 간 피어링을 통해 다른 ExpressRoute 회로에 전달됩니다. 리소스에 대한 액세스를 제한하도록 온-프레미스에서 네트워크 트래픽 필터링을 설정하는 것이 좋습니다.

FastPath

FastPath는 Azure 네트워크의 진입점에서 Microsoft Edge 교환을 구현합니다. FastPath는 대부분의 데이터 패킷에 대한 네트워크 홉을 줄입니다. 결과적으로 FastPath는 네트워크 대기 시간을 줄이고 애플리케이션 성능을 개선하며 Azure에 대한 새 ExpressRoute 연결의 기본 구성입니다.

기존 ExpressRoute 회로의 경우 Azure 지원에 문의하여 FastPath를 활성화하세요.

FastPath는 가상 네트워크 피어링을 지원하지 않습니다. ExpressRoute에 연결된 가상 네트워크가 다른 가상 네트워크와 피어되는 경우 온-프레미스 네트워크에서 다른 스포크 가상 네트워크로의 트래픽은 가상 네트워크 게이트웨이를 통해 라우팅됩니다. 이 문제를 해결하려면 모든 가상 네트워크를 ExpressRoute 회로에 직접 연결합니다.

부하 분산 장치

SAP Web Dispatcher 는 SAP 애플리케이션 서버 풀에 대한 HTTP 및 HTTPS 트래픽의 부하 분산을 처리합니다. 이 소프트웨어 부하 분산 장치는 SSL 종료 및 기타 오프로드 기능을 수행할 수 있는 ISO 네트워킹 모델의 계층 7이라고 하는 애플리케이션 계층 서비스를 제공합니다.

Azure Load Balancer는 데이터 스트림의 5튜플 해시를 사용하여 트래픽을 균등하게 분산하는 네트워크 전송 계층 서비스(계층 4)입니다. 해시는 원본 IP 주소, 원본 포트, 대상 IP 주소, 대상 포트 및 프로토콜 유형을 기반으로 합니다. Load Balancer는 오류가 있는 경우 클러스터 설정에서 기본 서비스 인스턴스 또는 정상 노드로 트래픽을 전송합니다. 모든 SAP 시나리오에 표준 Load Balancer 를 사용하는 것이 좋습니다. 표준 Load Balancer는 기본적으로 안전하며 표준 Load Balancer 뒤에 있는 VM에는 아웃바운드 인터넷 연결이 없습니다. VM에서 아웃바운드 인터넷을 사용하도록 설정하려면 표준 Load Balancer 구성을 조정해야 합니다.

DIAG(동적 정보 및 작업 게이트웨이) 프로토콜 또는 RFC를 통해 SAP 서버에 연결하는 SAP GUI 클라이언트의 트래픽의 경우 Central Services 메시지 서버는 SAP 애플리케이션 서버 로그온 그룹을 통해 부하를 분산합니다. 추가 부하 분산 장치가 필요하지 않습니다.

스토리지

일부 고객은 자신들의 애플리케이션 서버에 표준 스토리지를 사용합니다. 표준 관리 디스크는 지원되지 않으므로 모든 시나리오에서 Azure Premium SSD 또는 Azure NetApp Files 를 사용하는 것이 좋습니다. SAP note 2015553 대한 최근 업데이트는 몇 가지 특정 사용 사례에 대해 Azure Standard HDD 스토리지 및 Azure Standard SSD 스토리지의 사용을 제외합니다.

애플리케이션 서버는 비즈니스 데이터를 호스트하지 않으므로 더 작은 P4 및 P6 프리미엄 디스크를 사용하여 비용을 관리할 수도 있습니다. SAP 애플리케이션의 경우 Azure SSD v1, SSD v2 또는 Ultra Disks를 사용하는 것이 좋습니다. 스토리지 유형이 VM 가용성 SLA에 미치는 영향을 이해하려면 온라인 서비스에 대한 SLA를 참조하세요. HA 시나리오의 경우 Azure 공유 디스크 기능은 Azure Premium SSD 및 Azure Ultra Disk Storage에서 사용할 수 있습니다. 자세한 내용은 Azure 관리 디스크 및 Azure 관리 디스크 유형을 참조하세요.

Windows Server, SLES 15 SP1 이상 또는 SAP용 SLES에서 Azure 공유 디스크를 사용할 수 있습니다. Linux 클러스터에서 Azure 공유 디스크를 사용하는 경우 Azure 공유 디스크는 실패한 노드 블록 디바이스를 펜싱하는 역할을 합니다. 클러스터 네트워크 분할 시나리오에서 쿼럼 투표를 제공합니다. 이 공유 디스크에는 파일 시스템이 없으며 여러 클러스터 멤버 VM의 동시 쓰기를 지원하지 않습니다.

Azure NetApp Files에는 NFS 및 SMB용 기본 제공 파일 공유 기능이 있습니다.

NFS 공유 시나리오의 경우 Azure NetApp Files는 /hana/shared, /hana/data, 및 /hana/log 볼륨에 사용할 수 있는 NFS 공유에 대한 HA를 제공합니다. 가용성 보장은 온라인 서비스에 대한 SLA를 참조하세요. Azure NetApp Files 기반의 NFS 공유를 /hana/data 및 /hana/log 볼륨에 사용하는 경우, NFS v4.1 프로토콜을 사용해야 합니다. /hana/shared 볼륨의 경우 NFS v3 프로토콜이 지원됩니다.

백업 데이터 저장소에는 Azure 쿨 및 보관 액세스 계층을 사용하는 것이 좋습니다. 이러한 스토리지 계층은 자주 액세스되지 않는 수명이 긴 데이터를 저장하는 비용 효율적인 방법입니다. 또한 Azure NetApp Files 표준 계층 을 백업 대상으로 사용하거나 Azure NetApp Files 백업 옵션으로 사용하는 것이 좋습니다. 관리 디스크의 경우 권장되는 백업 데이터 계층은 Azure 쿨 또는 보관 액세스 계층입니다.

Ultra Disk Storage 및 Azure NetApp Files Ultra 계층 은 디스크 대기 시간을 크게 줄이고 중요한 애플리케이션 및 SAP 데이터베이스 서버의 성능을 향상시킵니다.

프리미엄 SSD v2 는 SAP와 같은 성능에 중요한 워크로드를 위해 설계되었습니다. 이 스토리지 솔루션의 이점 및 제한 사항에 대한 자세한 내용은 프리미엄 SSD v2 배포를 참조하세요.

성능 고려 사항

SAP 애플리케이션 서버는 데이터베이스 서버와 지속적으로 통신합니다. SAP HANA를 비롯한 모든 데이터베이스 플랫폼에서 실행되는 성능에 중요한 애플리케이션의 경우 프리미엄 SSD v1을 사용하는 경우 로그 볼륨에 대해 Write Accelerator 를 사용하도록 설정합니다. 이 방법은 로그 쓰기 대기 시간을 향상시킬 수 있습니다. 프리미엄 SSD v2는 Write Accelerator를 사용하지 않습니다. 쓰기 가속기는 M 시리즈 VM에 사용할 수 있습니다.

서버 간 통신을 최적화하려면 가속화된 네트워킹를 사용합니다. 둘 이상의 vCPU가 있는 대부분의 범용 및 컴퓨팅 최적화 VM 인스턴스 크기는 가속화된 네트워킹을 지원합니다. 하이퍼 스레딩을 지원하는 인스턴스에서 4개 이상의 vCPU가 있는 VM 인스턴스는 가속화된 네트워킹을 지원합니다.

일관된 성능을 얻으려면 네트워크 인터페이스에서 Linux TCP/IP 스택 및 버퍼 를 최적화해야 합니다. Microsoft 권장 설정을 따릅니다. 예를 들어 다음과 같은 항목을 조정합니다.

  • 읽기 및 쓰기 메모리 버퍼를 최적화하는 커널 매개 변수
  • BBR(병목 대역폭 및 왕복 전파 시간) 혼잡 제어
  • TCP 매개 변수를 조정하여 일관성 및 처리량 향상
  • TX/RX용 NIC 링 버퍼

SAP HANA 성능 요구 사항에 대한 자세한 내용은 SAP 참고 1943937 참조하세요.

IOPS(초당 높은 입출력 작업) 및 디스크 대역폭 처리량을 달성하려면 스토리지 볼륨 성능 최적화에 대한 일반적인 사례를 따르세요. 예를 들어 여러 디스크를 결합하여 스트라이프 디스크 볼륨을 만들면 입력/출력(I/O) 성능이 향상될 수 있습니다. 자주 변경되지 않는 스토리지 콘텐츠에서 읽기 캐시를 사용하도록 설정하면 데이터 검색 속도가 빨라집니다. 자세한 내용은 SAP HANA Azure 가상 머신 스토리지 구성을 참조하세요.

프리미엄 SSD v2는 SAP와 같은 성능에 중요한 워크로드를 위해 설계되었습니다. 이점, 제한 사항 및 최적 사용 시나리오에 대한 자세한 내용은 Azure 관리 디스크 유형을 참조하세요.

Ultra Disk Storage는 SAP HANA와 같이 애플리케이션의 집약적인 IOPS 및 전송 대역폭 요구를 충족하는 새로운 세대의 스토리지입니다. VM을 다시 부팅하지 않고도 울트라 디스크의 성능을 동적으로 변경하고 IOPS 및 MBps와 같은 메트릭을 독립적으로 구성할 수 있습니다. 가능한 경우 쓰기 가속기 대신 Ultra Disk Storage를 사용하는 것이 좋습니다.

일부 SAP 애플리케이션은 데이터베이스와 자주 통신해야 합니다. 거리 때문에 애플리케이션과 데이터베이스 계층 간의 네트워크 대기 시간은 애플리케이션 성능에 부정적인 영향을 줄 수 있습니다. Azure 근접 배치 그룹은 가용성 집합에 배포된 VM의 배치 제약 조건을 설정합니다. 그룹의 논리적 구문 내에서 공동 배치 및 성능은 확장성, 가용성 및 비용보다 선호됩니다. 근접 배치 그룹에서는 대부분의 SAP 애플리케이션의 사용자 환경을 크게 향상시킬 수 있습니다.

애플리케이션과 SAP 애플리케이션 스택의 데이터베이스 계층 간에 NVA(네트워크 가상 어플라이언스)의 배치는 지원되지 않습니다. NVA는 데이터 패킷을 처리하는 데 상당한 시간이 필요합니다. 결과적으로 애플리케이션 성능이 허용할 수 없을 정도로 느려집니다.

또한 가용성 영역을 사용하여 리소스를 배포할 때 성능을 고려하여 서비스 가용성을 향상시키는 것이 좋습니다. 대상 지역의 모든 영역 간에 명확한 네트워크 대기 시간 프로필을 만드는 것이 좋습니다. 이 접근 방식을 사용하면 영역 간의 최소 대기 시간으로 리소스 배치를 결정하는 데 도움이 됩니다. 이 프로필을 만들려면 각 영역에 작은 VM을 배포하여 테스트를 실행합니다. 테스트에 권장되는 도구에는 PsPing 및 Iperf가 포함됩니다. 테스트 후 이러한 VM을 제거합니다. 대신 사용할 수 있는 공용 도메인 네트워크 대기 시간 테스트 도구는 가용성 영역 대기 시간 테스트를 참조하세요.

Azure NetApp Files에는 가장 까다로운 SAP 환경의 요구 사항을 충족하기 위해 실시간 튜닝을 가능하게 하는 고유한 성능 기능이 있습니다. Azure NetApp Files를 사용하는 경우 성능 고려 사항은 Azure NetApp Files의 HANA 데이터베이스 크기 조정을 참조하세요.

확장성 고려 사항

SAP 애플리케이션 계층에서 Azure는 스케일 업 및 스케일 아웃을 위한 다양한 VM 크기를 제공합니다. 포괄 목록은 Azure의 SAP 애플리케이션: SAP 참고 1928533 지원되는 제품 및 Azure VM 유형을 참조하세요. 더 많은 VM 유형이 지속적으로 인증되므로 동일한 클라우드 배포에서 스케일 업 또는 스케일 다운할 수 있습니다.

데이터베이스 계층에서 이 아키텍처는 한 인스턴스에서 최대 24TB(테라바이트)까지 확장할 수 있는 Azure VM에서 SAP S/4HANA 애플리케이션을 실행합니다. 워크로드가 최대 VM 크기를 초과하는 경우 온라인 트랜잭션 처리 애플리케이션에 대해 최대 96TB(4개의 24TB 인스턴스)에 대해 다중 노드 구성을 사용할 수 있습니다. 자세한 내용은 인증 및 지원되는 SAP HANA 하드웨어 디렉터리를 참조하세요.

가용성 고려 사항

리소스 중복성은 고가용성 인프라 솔루션의 일반적인 주제입니다. 다양한 스토리지 유형에 대한 단일 인스턴스 VM 가용성 SLA는 온라인 서비스에 대한 SLA를 참조하세요. Azure에서 서비스 가용성을 높이려면 유연한 오케스트레이션, 가용성 영역 및 가용성 집합을 제공하는 Azure Virtual Machine Scale Sets를 사용하여 VM 리소스를 배포합니다.

Azure 지역 가용성 집합 배포 모델은 지원되는 옵션입니다. 그러나 가용성을 향상시키고 배포 유연성을 높이기 위해 새 SAP 배포를 위한 가용성 영역 모델이 있는 가상 머신 확장 집합을 채택하는 것이 좋습니다.

SAP 애플리케이션의 분산 설치에서는 HA를 달성하기 위해 기본 설치가 복제됩니다. 아키텍처의 각 계층에 대해 HA 디자인은 다양합니다.

배포 방법

Azure에서 SAP 워크로드 배포는 SAP 애플리케이션의 가용성 및 복원력 요구 사항에 따라 지역 또는 영역이 될 수 있습니다. Azure는 유연한 오케스트레이션(하나의 장애 도메인 구성), 가용성 영역 및 가용성 집합이 있는 Virtual Machine Scale Sets와 같은 다양한 배포 옵션을 제공하여 리소스의 가용성을 향상시킵니다.

Azure에 대한 고객 배포가 수년에 걸쳐 증가함에 따라 Microsoft는 클라우드 탄력성 및 복원력을 보장하기 위해 Virtual Machine Scale Sets를 포함하도록 Azure VM 배포 모델을 개선했습니다. 사용 가능한 배포 옵션을 고려할 때 모든 새 배포에 Azure 유연한 확장 집합 영역 배포를 사용하는 것이 좋습니다. 영역 간, 단일 영역 내 및 영역이 없는 지역에서 배포하는 방법에 대한 자세한 내용은 SAP NetWeaver에 대한 HA 아키텍처 및 시나리오를 참조하세요.

애플리케이션 서버 계층의 Web Dispatcher

중복 Web Dispatcher 인스턴스를 사용하여 HA를 달성할 수 있습니다. 자세한 내용은 SAP Web Dispatcher를 참조하세요. 가용성 수준은 Web Dispatcher 뒤에 있는 애플리케이션의 크기에 따라 달라집니다. 확장성 문제가 거의 없는 소규모 배포에서는 ASCS VM을 사용하여 Web Dispatcher를 공동 배치할 수 있습니다. 이 방법을 사용하면 독립 운영 체제 유지 관리를 절약하고 동시에 HA를 얻을 수 있습니다.

애플리케이션 서버 계층에 있는 중앙 서비스

Azure Linux VM의 Central Services HA의 경우 선택한 Linux 배포에 적절한 HA 확장을 사용합니다. SUSE 분산 복제 블록 디바이스 또는 Red Hat GlusterFS를 사용하여 고가용성 NFS 스토리지에 공유 파일 시스템을 배치하는 것이 관례입니다. 고가용성 NFS를 제공하고 NFS 클러스터의 필요성을 없애기 위해 Azure Files 또는 Azure NetApp Files를 통해 NFS와 같은 다른 비용 효과적이거나 강력한 솔루션을 사용할 수 있습니다. Azure NetApp Files 공유는 SAP HANA 데이터 및 로그 파일을 호스트할 수 있습니다. 이 설정을 사용하면 대기 노드가 있는 HANA 스케일 아웃 배포 모델을 사용할 수 있으며 Azure Files를 통한 NFS는 고가용성 비 데이터베이스 파일 공유에 적합합니다.

이제 Azure Files를 통한 NFS는 SLES 및 RHEL 모두에 대해 고가용성 파일 공유를 지원합니다. 이 솔루션은 SAP 설치에서 /sapmnt 및 /saptrans와 같은 고가용성 파일 공유에 적합합니다.

Azure NetApp Files는 SLES에서 ASCS의 HA를 지원합니다. RHEL HA의 ASCS에 대한 자세한 내용은 Linux용 SIOS Protection Suite를 참조하세요.

향상된 Azure 펜스 에이전트는 SUSE 및 Red Hat 모두에서 사용할 수 있으며 이전 버전의 에이전트보다 훨씬 빠른 서비스 장애 조치(failover)를 제공합니다.

또 다른 펜싱 옵션은 펜싱 디바이스에 Azure 공유 디스크 를 사용하는 것입니다. SAP 15 SP1 이상용 SLES 15 SP1 또는 SLES에서는 Azure 공유 디스크를 사용하여 Pacemaker 클러스터를 설정할 수 있습니다. 이 옵션은 간단하며 Azure 펜스 에이전트와 같은 개방형 네트워크 포트가 필요하지 않습니다.

SLES 15 이상에서 최근에 지원되고 간단한 Pacemaker 구성은 SAP 애플리케이션 VM용 SLES에서 간단한 탑재 및 NFS를 사용하는 HA SAP NetWeaver입니다. 이 구성에서 SAP 파일 공유는 클러스터 관리에서 제거되므로 더 간단하게 작동할 수 있습니다. 모든 새 배포에 이 HA 구성을 사용합니다.

Linux 클러스터는 대규모 SAP 환경의 비용을 추가로 관리하기 위해 Azure에서 ASCS 다중 SID 설치 를 지원합니다. 여러 SAP 시스템 간에 가용성 클러스터를 공유하면 SAP 환경이 간소화되고 운영 비용이 절감됩니다.

표준 Load Balancer에서 HA 포트 를 사용하도록 설정하고 많은 SAP 포트에 대한 부하 분산 규칙을 구성할 필요가 없습니다. 일반적으로 부하 분산 장치를 설정할 때 DSR(Direct Server Return) 기능을 사용하도록 설정하면 클라이언트 조회에 대한 서버 응답이 부하 분산 장치를 우회할 수 있습니다. 이 기능을 부동 IP라고도 합니다. 부하 분산 장치는 온-프레미스 또는 Azure에 있을 수 있습니다. 이 직접 연결은 부하 분산 장치가 데이터 전송 경로에서 병목 상태가 되지 않도록 합니다. ASCS 및 HANA 데이터베이스 클러스터의 경우 DSR을 사용하도록 설정하는 것이 좋습니다. 백 엔드 풀의 VM에 퍼블릭 아웃바운드 연결이 필요한 경우 추가 구성 이 필요합니다.

DIAG 프로토콜 또는 RFC를 통해 SAP 서버에 연결하는 SAP GUI 클라이언트의 트래픽에 대해 Central Services 메시지 서버는 SAP 애플리케이션 서버 로그온 그룹을 사용하여 부하를 분산합니다. 추가 부하 분산 장치가 필요하지 않습니다.

애플리케이션 서버 계층의 애플리케이션 서버

애플리케이션 서버 풀 내에서 트래픽 부하를 분산하여 HA를 달성할 수 있습니다.

데이터베이스 계층

이 가이드의 아키텍처는 두 개의 Azure VM으로 구성된 고가용성 SAP HANA 데이터베이스 시스템을 보여 줍니다. 데이터베이스 계층의 네이티브 시스템 복제 기능은 복제된 노드 간에 수동 또는 자동 장애 조치(failover)를 제공합니다.

  • 수동 장애 조치의 경우 둘 이상의 HANA 인스턴스를 배포하고 HSR을 사용합니다.

  • 자동 장애 조치용으로 Linux 배포판에 HSR과 Linux HA 확장(HAE)을 모두 사용하세요. Linux HAE는 HANA 리소스에 대한 클러스터 서비스를 제공하고, 오류 이벤트를 검색하고, 잘못된 서비스의 장애 조치(failover)를 정상 노드로 오케스트레이션합니다.

가용성 영역에 VM 배포

가용성 영역은 서비스 가용성을 향상시킬 수 있습니다. 영역은 특정 Azure 지역 내에서 물리적으로 구분된 위치를 나타냅니다. 워크로드 가용성을 개선하고 데이터 센터 중단으로부터 애플리케이션 서비스 및 VM을 보호합니다. 단일 영역의 VM은 단일 업데이트 또는 장애 도메인에 있는 것처럼 처리됩니다. 영역 배포를 선택하면 동일한 영역의 VM이 장애 도메인 및 업그레이드 도메인에 최대한 배포됩니다.

이 기능을 지원하는 Azure 지역에서 는 최소 3개의 영역을 사용할 수 있습니다. 이러한 영역의 데이터 센터 간의 최대 거리는 보장되지 않습니다. 여러 계층 SAP 시스템을 여러 영역에 배포하려면 영역 내 및 대상 영역 간의 네트워크 대기 시간과 배포된 애플리케이션이 네트워크 대기 시간에 얼마나 중요한지 알고 있어야 합니다.

가용성 영역에 리소스를 배포하기로 결정하는 경우 다음 고려 사항을 생각해야 합니다.

  • 한 영역의 VM 간 대기 시간
  • 선택한 영역의 VM 간 대기 시간
  • 선택한 영역에서 동일한 Azure 서비스 또는 VM 유형의 가용성

비고

DR의 가용성 영역은 권장하지 않습니다. DR 사이트는 자연 재해를 고려하기 위해 기본 사이트에서 적어도 100 마일이어야합니다. 데이터 센터 간의 정확한 거리를 보장할 수 없습니다.

활성/수동 배포 예제

이 배포 예제에서 액티브/패시브 상태는 영역 내의 애플리케이션 서비스 상태를 나타냅니다. 애플리케이션 계층에서 SAP 시스템의 활성 애플리케이션 서버 4개는 모두 영역 1에 있습니다. 수동 애플리케이션 서버 4개로 구성된 또 다른 세트는 영역 2에 빌드되지만 종료됩니다. 필요한 경우에만 활성화됩니다.

Central Services 및 데이터베이스에 대한 2노드 클러스터는 두 영역에 걸쳐 확장됩니다. 영역 1이 실패하면 Central Services와 데이터베이스 서비스가 영역 2에서 실행됩니다. 영역 2의 수동 애플리케이션 서버가 활성화됩니다. 이 SAP 시스템의 모든 구성 요소가 동일한 영역에 배치되면 네트워크 대기 시간이 최소화됩니다.

활성/활성 방식 배포 예시

활성/활성 배포에서는 두 개의 영역에 걸쳐 두 개의 애플리케이션 서버 집합이 빌드됩니다. 각 영역에서 각 집합의 두 애플리케이션 서버가 활성 상태입니다. 따라서 정상 작업에서 두 영역 모두에 활성 애플리케이션 서버가 있습니다.

ASCS 및 데이터베이스 서비스는 영역 1에서 실행됩니다. 영역 2의 애플리케이션 서버는 영역 간의 물리적 거리 때문에 ASCS 및 데이터베이스 서비스에 연결할 때 네트워크 대기 시간이 길어질 수 있습니다.

영역 1이 오프라인 상태가 되면 ASCS 및 데이터베이스 서비스가 영역 2로 장애 조치됩니다. 휴면 애플리케이션 서버를 온라인으로 가져와 애플리케이션 처리를 위한 전체 용량을 제공할 수 있습니다.

DR 고려 사항

SAP 애플리케이션 스택의 모든 계층은 다른 접근 방식을 사용하여 DR 보호를 제공합니다. DR 전략 및 구현 정보는 SAP 워크로드에 대한 DR 개요 및 인프라 지침 및 SAP 애플리케이션에 대한 DR 지침을 참조하세요.

비고

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

DR 지역에 사용 가능한 리소스 용량을 보장하려면 주문형 용량 예약을 사용합니다. Azure를 사용하면 예약 인스턴스 할인을 용량 예약과 결합하여 비용을 절감할 수 있습니다.

비용 고려 사항

Azure 가격 계산기를 사용하여 비용을 예측합니다.

자세한 내용은 Azure Well-Architected Framework 비용 최적화를 참조하세요.

가상 머신들

이 아키텍처는 관리, SAP 애플리케이션 및 데이터베이스 계층에 대해 Linux를 실행하는 VM을 사용합니다.

VM에 대한 몇 가지 결제 옵션은 다음과 같습니다.

  • 예측 가능한 완료 시간 또는 리소스 사용 시간이 없는 워크로드의 경우 종량제 옵션을 고려합니다.

  • 1년 또는 3년 기간 동안 VM 사용을 커밋할 수 있는 경우 Azure 예약 을 사용하는 것이 좋습니다. VM 예약은 비용을 크게 줄일 수 있습니다. 사용량에 따른 요금제에 비해 최대 72%를 절감할 수 있습니다.

  • Azure 스폿 VM을 사용하여 중단될 수 있으며 미리 결정된 시간 범위 또는 SLA 내에서 완료할 필요가 없는 워크로드를 실행합니다. Azure는 사용 가능한 용량이 있을 때 스폿 VM을 배포하고 용량이 다시 필요할 때 제거합니다. 스폿 VM 비용은 다른 VM보다 낮습니다. 다음과 같은 워크로드에는 스폿 VM을 사용하는 것이 좋습니다.

    • 고성능 컴퓨팅 시나리오, 일괄 처리 작업 또는 시각적 렌더링 애플리케이션

    • 연속 통합 및 지속적인 업데이트 워크로드를 포함한 테스트 환경

    • 대규모 상태 비저장 애플리케이션

  • Azure Reserved Virtual Machine Instances는 예측 가능하고 가변적인 워크로드에서 비용을 관리할 수 있도록 Azure Reserved Virtual Machine Instances 요금을 종량제 구독과 결합하여 총 소유 비용을 줄일 수 있습니다. 자세한 내용은 Azure Reserved Virtual Machine Instances를 참조하세요.

가격 책정에 대한 개요는 Linux 가상 머신 가격 책정을 참조하세요.

부하 분산기

이 시나리오에서는 Azure Load Balancer를 사용하여 애플리케이션 계층 서브넷의 VM에 트래픽을 분산합니다.

구성된 부하 분산 및 아웃바운드 규칙 수에 대해서만 요금이 청구됩니다. 인바운드 네트워크 주소 변환 규칙은 무료입니다. 규칙을 구성하지 않으면 표준 Load Balancer에 대한 시간당 요금이 청구되지 않습니다.

익스프레스라우트

이 아키텍처의 경우 ExpressRoute는 온-프레미스 네트워크와 Azure 가상 네트워크 간에 프라이빗 연결을 만들기 위해 사용되는 네트워킹 서비스입니다.

모든 인바운드 데이터 전송은 무료입니다. 모든 아웃바운드 데이터 전송은 미리 결정된 속도에 따라 요금이 청구됩니다. 자세한 내용은 ExpressRoute 가격 책정을 참조 하세요.

관리 및 운영 고려 사항

프로덕션 환경에서 시스템을 계속 실행하려면 다음 사항을 고려합니다.

SAP 솔루션용 Azure 센터

Azure Center for SAP solutions는 SAP 시스템을 Azure에서 통합 워크로드로 만들고 실행할 수 있게 하며 혁신을 위한 보다 원활한 기반을 제공하는 엔드투엔드 솔루션입니다. SAP 솔루션용 Azure 센터 배포 환경은 SAP 시스템을 실행하는 데 필요한 컴퓨팅, 스토리지 및 네트워킹 구성 요소를 만듭니다. 그런 다음 Microsoft 모범 사례에 따라 SAP 소프트웨어 설치를 자동화할 수 있습니다. 신규 및 기존 Azure 기반 SAP 시스템 모두에 대한 관리 기능을 활용할 수 있습니다.

백업

여러 가지 방법으로 SAP HANA 데이터를 백업할 수 있습니다. Azure로 마이그레이션한 후에는 기존 백업 솔루션을 계속 사용합니다. Azure는 백업에 대한 두 가지 네이티브 접근 방식을 제공합니다. VM에서 SAP HANA를 백업하거나 파일 수준에서 Azure Backup을 사용할 수 있습니다. Azure Backup은 SAP 에서 Backint 인증을 받았습니다 . 자세한 내용은 Azure VM에서 SAP HANA 데이터베이스의 백업에 대한 Azure Backup FAQ 및 지원 매트릭스를 참조하세요.

비고

HANA 단일 컨테이너 또는 확장 배포만 Azure Storage 스냅샷을 지원합니다.

ID 관리

중앙 집중식 ID 관리 시스템을 사용하여 모든 수준에서 리소스에 대한 액세스를 제어합니다.

모니터링

Azure에서 애플리케이션 및 서비스의 가용성 및 성능을 최대화하려면 Azure Monitor를 사용합니다. Azure Monitor는 클라우드 및 온-프레미스 환경에서 원격 분석의 수집, 분석 및 작업에 대한 포괄적인 솔루션을 제공합니다. Azure Monitor는 애플리케이션이 수행되는 방식을 보여 주고 영향을 주는 문제 및 애플리케이션이 의존하는 리소스를 사전에 식별합니다. SAP HANA 및 기타 주요 데이터베이스 솔루션에서 실행되는 SAP 애플리케이션의 경우 SAP용 Azure Monitor가 SAP 서비스 가용성 및 성능을 관리하는 데 어떻게 도움이 되는지 알아보려면 SAP용 Azure Monitor 솔루션을 참조하세요.

보안 고려 사항

SAP에는 SAP 애플리케이션 및 데이터베이스 내에서 역할 기반 액세스 및 권한 부여를 제어하는 자체 사용자 관리 엔진이 있습니다. 자세한 내용은 SAP HANA 보안 개요를 참조하세요.

네트워크 보안을 강화하려면 NVA를 사용하여 Web Dispatcher 및 Fiori 프런트 엔드 서버 풀의 서브넷 앞에 방화벽을 만드는 경계 네트워크를 사용하는 것이 좋습니다. 데이터 전송 비용을 최소화하려면 S/4 시스템과 동일한 가상 네트워크 내에서 Fiori 애플리케이션을 호스트하는 활성 프런트 엔드 서버를 배포합니다. 또는 가상 네트워크 피어링을 활용하여 S/4 시스템과의 연결을 설정하는 경계 네트워크에서 이러한 프런트 엔드 서버를 구성할 수 있습니다.

인프라 보안을 위해 전송 중 데이터와 미사용 데이터가 암호화됩니다. S/4HANA에 적용되는 네트워크 보안에 대한 자세한 내용은 SAP 환경의 보안을 참조하세요.

Linux VM 디스크를 암호화하려면 몇 가지 옵션이 있습니다. SAP HANA 미사용 데이터 암호화의 경우 SAP HANA 네이티브 암호화 기술을 사용하는 것이 좋습니다. 특정 Linux 배포, 버전 및 이미지에서 Azure 디스크 암호화를 지원하려면 Linux VM용 Azure Disk Encryption을 참조하세요.

비고

동일한 스토리지 볼륨에서 HANA 미사용 데이터 암호화 및 Azure Disk Encryption을 사용하지 마세요. HANA의 경우 Azure 디스크 스토리지 서버 쪽 암호화를 통해 HANA 데이터 암호화를 사용합니다. 고객 관리형 키를 사용하면 I/O 처리량에 영향을 줄 수 있습니다.

커뮤니티

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

기여자

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

대표 저자:

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

다음 단계

이 아키텍처와 동일한 기술 중 일부를 사용하는 SAP 워크로드에 대한 자세한 내용 및 예제는 다음 문서를 참조하세요.