Azure 기반 Linux의 SAP S/4HANA

ExpressRoute
Azure의 SAP HANA(대규모 인스턴스)
Virtual Machines
Virtual Network
Azure NetApp Files

이 참조 아키텍처는 Azure 내의 재해 복구를 지원하는 고가용성 환경에서 S/4HANA와 HANA에서의 Suite 실행을 위한 검증된 사례 세트를 보여줍니다. Fiori 정보는 S/4HANA 애플리케이션에만 적용됩니다.

Azure의 Linux Virtual Machines용 SAP S/4HANA를 위한 참조 아키텍처

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

참고

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

Architecture

이 참조 아키텍처는 일반적인 프로덕션 시스템을 설명합니다. 이 아키텍처는 조직의 요구 사항에 맞게 변경할 수 있는 가상 머신 크기로 배포됩니다. 이 구성은 비즈니스 요구 사항에 맞게 단일 가상 머신으로 줄일 수 있습니다.

아키텍처 보안 주제를 시연하기 위해 네트워크 레이아웃이 크게 간소화되었으며 이는 전체 엔터프라이즈 네트워크를 설명하는 것은 아닙니다.

다음 구성 요소가 필요합니다.

Azure Virtual Network. Azure VNet(Virtual Network) 서비스는 Azure 리소스를 서로 안전하게 연결합니다. 이 아키텍처에서 VNet은 허브-스포크 토폴로지의 허브에 배포된 게이트웨이를 통해 온-프레미스 환경에 연결합니다. 스포크는 SAP 애플리케이션과 데이터베이스 계층을 위해 사용되는 VNet입니다.

가상 네트워크 피어링. 이 아키텍처는 함께 피어되는여러 가상 네트워크를 사용합니다. 이 토폴로지는 Azure에 배포된 서비스에 대한 네트워크 조각화 및 격리를 제공합니다. 피어링은 Microsoft 백본 네트워크를 통해 투명하게 네트워크를 연결하며 단일 지역 내에서 구현되는 경우 성능 저하를 야기하지 않습니다. 개별 서브넷은 각 계층 애플리케이션(SAP NetWeaver), 데이터베이스 및 공유 서비스(예: jumpbox 및 Active Directory)에 사용됩니다.

가상 머신 이 아키텍처는 애플리케이션 계층과 데이터베이스 계층에 대해 다음과 같이 그룹화되어 Linux를 실행하는 가상 머신을 사용합니다.

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

  • SAP HANA 데이터베이스 계층은 클러스터에 있는 둘 이상의 Linux 가상 머신을 사용하여 스케일 업 배포에서 고가용성을 구현합니다. HSR(HANA 시스템 복제)을 사용하여 주 및 보조 HANA 시스템 간에 콘텐츠를 복제합니다. Linux 클러스터링을 사용하여 시스템 장애를 감지하고 자동 장애 조치를 용이하게 합니다. 실패한 시스템이 격리되었거나 종료되었는지 확인하여 클러스터 분할 브레인 상태를 방지하려면 스토리지 기반 또는 클라우드 기반 펜싱 메커니즘을 사용해야 합니다. HANA 스케일 아웃 배포에서는 Linux 클러스터링 구성 요소가 없어도 대기 노드를 구성하여 데이터베이스 고가용성을 달성할 수 있습니다.

  • Jumpbox. 베스천 호스트라고도 불리는 네트워크 내의 이 보안 가상 머신은 다른 가상 머신에 연결되는 데 사용되며, 일반적으로 도메인 컨트롤러 및 백업 서비스와 같은 공유 서비스의 일부로 배포됩니다. Jumpbox는 가상 머신에 배포되어 SAP HANA Studio, SAPGUI, 파일 전송, 그리고 일반적으로 설치 및 관리 목적으로 사용되는 기타 기능을 지원합니다. RDP(원격 데스크톱 프로토콜) 또는 SSH(보안 셸) 서비스의 경우 Azure Bastion. 관리에 RDP와 SSH만 사용하는 경우 Azure Bastion이 훌륭한 대안입니다.

부하 분산. 애플리케이션 계층 서브넷의 가상 머신에 트래픽을 분산하기 위해 부하 분산기가 사용됩니다. Azure 영역을 사용하는 경우 표준 Load Balancer를 사용합니다. 표준 Load Balancer 기본적으로 안전하며 표준 Load Balancer 뒤에 있는 가상 머신이 아웃바운드 인터넷에 연결되지 않는다는 점을 강조해야 합니다. 가상 머신에서 아웃바운드 인터넷을 사용하도록 설정하려면 표준 Load Balancer 구성을 고려해야 합니다. 고가용성을 위해 트래픽 유형(예: HTTP 또는 SAP GUI) 또는 필요한 네트워크 서비스(예: SSL(SSL(Secure Sockets Layer)) 종료)에 따라 기본 제공 SAP Web Dispatcher, Azure Load Balancer 또는 다른 메커니즘을 사용합니다.

가용성 집합. 모든 풀 및 클러스터(Web Dispatcher, SAP 애플리케이션 서버, Central Services 및 HANA)에 대한 가상 머신은 별도의 가용성 집합으로그룹화되며 역할당 두 개 이상의 가상 머신이 프로비전됩니다. 가용성 집합은 여러 호스트에 역할 인스턴스를 배포하여 호스트 시스템 오류 또는 유지 관리 이벤트의 관리를 통해 애플리케이션과 가상 머신의 가용성을 높입니다. 대안은 이 문서의 후반부에 설명된 대로 가용성 영역 사용하여 워크로드 가용성을 개선하는 것입니다.

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

근접 배치 그룹입니다. 이 논리 그룹은 가용성 집합 또는 가상 머신 확장 집합에 배포된 VM에 제약 조건을 부여합니다. 근접 배치 그룹은 애플리케이션 대기 시간을 최소화하기 위해 가상 머신이 동일한 데이터 센터에 상주한다는 의미의 배치를 선호합니다.

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

애플리케이션 보안 그룹. 워크로드에 따라 세분화된 네트워크 보안 정책을 정의하고 애플리케이션을 중심으로 하려면 명시적 IP 주소 대신 애플리케이션 보안 그룹을 사용합니다. 네트워크의 신뢰할 수 있는 세그먼트에서 트래픽을 필터링하여 이름 및 보안 애플리케이션을 기준으로 가상 머신을 그룹화할 수 있습니다.

게이트웨이 게이트웨이는 고유한 네트워크를 연결하여 온-프레미스 네트워크를 Azure VNet으로 확장합니다. ExpressRoute는 공용 인터넷을 통해 이동하지 않는 프라이빗 연결을 만드는 데 권장되는 Azure 서비스이지만 사이트간 연결을 사용할 수도 있습니다. 대기 시간을 줄이기 위해 ExpressRoute Global ReachExpressRoute FastPath는 이 문서의 후반부에서 설명한 연결 옵션입니다.

Azure Storage. 가상 머신에 대한 데이터 지속성을 VHD(가상 하드 디스크) 형식으로 제공합니다. Azure Managed Disk를 권장합니다.

권장 사항

이 아키텍처는 소규모 프로덕션 수준의 배포를 설명합니다. 배포는 비즈니스 요구 사항에 따라 달라지며, 해당 권장 사항을 출발점으로 고려해야 합니다.

가상 머신

애플리케이션 서버 풀 및 클러스터에서 요구 사항에 따라 가상 머신 수를 조정합니다. Azure Virtual Machines 계획 및 구현 가이드에는 가상 머신에서 SAP NetWeaver를 실행하는 방법을 자세히 설명하며, 이 정보는 SAP S/4HANA 배포에도 적용됩니다.

Azure 가상 머신 유형 및 처리량 메트릭(SAPS)에 대한 SAP 지원에 대한 자세한 내용은 SAP Note 1928533. (SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 있어야 합니다.) SAP Certified and Supported SAP HANA Hardware Directory에는 HANA 데이터베이스에 대한 인증된 Azure 가상 머신 목록이 있습니다.

SAP Web Dispatcher

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

Fiori FES(프런트 엔드 서버)

이 아키텍처는 다양한 기본 요구 사항을 해결하며 포함된 Fiori FES 모델을 사용한다고 가정합니다. 모든 기술 구성 요소는 S/4 시스템 자체에 설치됩니다. 즉, 각 S/4 시스템에 자체 Fiori 실행 패드가 있습니다. 이 배포 모델에 대한 고가용성 설정은 S/4 시스템의 설정이며 추가 클러스터링 또는 가상 머신이 필요하지 않습니다. 그렇기 때문에 아키텍처 다이어그램에는 FES 구성 요소가 표시되지 않습니다.

SAP Fiori 배포 옵션 및 시스템 가로 권장 사항 문서에서는 시나리오에 따라 포함되거나 허브인 기본 배포 옵션을 설명합니다. 단순화 및 성능을 달성하기 위해 Fiori 기술 구성 요소와 S/4 애플리케이션 간의 소프트웨어 릴리스가 강력하게 결합되기 때문에, 소수의 좁은 사용 사례에 대해서만 허브 배포가 적합합니다.

FES 허브 배포를 사용하는 경우 FES는 클래식 SAP NetWeaver ABAP 스택에 대한 추가 기능 구성 요소입니다. 클러스터형이거나 대기 서버 데이터베이스 계층과 함께 다중 호스트 기능을 갖춘 3계층 ABAP 애플리케이션 스택, 그리고 공유 스토리지를 위해 고가용성 NFS를 갖추고 클러스터링된 ASCS 계층을 보호할 때와 동일한 방법으로 고가용성을 설정하고, 적어도 두 개의 애플리케이션 서버를 사용하세요. 트래픽은 클러스터형 또는 병렬 Web Dispatcher 쌍을 통해 부하 분산됩니다. 인터넷 연결 Fiori 앱의 경우 DMZ에서 FES 허브를 배포하는 것이 좋습니다. Azure Application Gateway/WAF를 중요한 구성 요소로 사용하여 사용자 인증을 위한 SAMLSAP Fiori용SSO를 사용하여 AAD 트래픽을 방어합니다. SAP Fiori의 참조 아키텍처

애플리케이션 서버 풀

ABAP 애플리케이션 서버에 대한 로그온 그룹을 관리하려면 로그온 사용자 부하 분산을 위해 SMLG 트랜잭션, 배치 서버 그룹에 SM61, RFC 그룹에 RZ12 등을 각각 사용하는 것이 일반적입니다. 해당 트랜잭션은 Central Services의 메시지 서버 내에서 부하 분산 기능을 사용하여 들어오는 세션 또는 워크로드를 SAPGUI 및 RFC 트래픽에 대한 SAP 애플리케이션 서버 풀 간에 배포합니다.

SAP Central Services 클러스터

Azure 단일 인스턴스 VM 가용성 SLA가 요구 사항을 충족하는 경우 Central Services를 단일 가상 머신에 배포할 수 있습니다. 하지만 가상 머신은 SAP 환경에 대해 잠재적으로 SPOF(단일 실패 지점)이 됩니다. 고가용성 Central Services 배포의경우 Azure NetApp Files 서비스 및 Central Services 클러스터가 사용됩니다.

또 다른 옵션은 Azure Shared Disks를 사용하여 고가용성을 달성하는 것입니다. SUSE Linux Enterprise Server 15 SP1 이상 또는 SAP 애플리케이션용 SUSE Linux Enterprise Server에서 Linux용 Azure 공유 디스크를사용하여 Pacemaker 클러스터를 설정할 수 있습니다.

또는 Linux 클러스터 공유 스토리지에 NFS 파일 공유를 사용할 수 있습니다.

Azure 배포에서 애플리케이션 서버는 Central Services 또는 ERS 서비스의 가상 호스트 이름을 통해 고가용성 Central Services에 연결합니다. 해당 호스트 이름은 부하 분산 장치의 클러스터 프런트 엔드 IP 구성에 할당됩니다. Azure Load Balancer는 여러 프런트 엔드 IP를 지원하므로, Central Services와 ERS VIP(Virtual IP) 모두 하나의 부하 분산 장치에 바인딩될 수 있습니다.

이제 Azure에서 ASCS 다중 SID 설치에 대한 Linux 클러스터 지원이 지원됩니다. 클러스터가 적을수록 SAP 환경을 간소화하는 데 도움이 됩니다.

가용성 집합

가용성 집합은 서버를 서로 다른 물리적 인프라로 배포하고 그룹을 업데이트하여 서비스 가용성을 향상시킵니다. Azure 인프라 유지 관리로 인한 가동 중지 시간을 방지하고 서비스 수준 계약(SLA)을충족하기 위해 동일한 역할을 수행하는 가상 머신을 가용성 집합에 배치합니다. 높은 SLA를 얻으려면 가용성 집합당 두 개 이상의 가상 머신이 필요합니다.

집합의 모든 가상 머신은 동일한 역할을 수행해야 합니다. 동일한 가용성 집합에 역할이 다른 서버를 혼합하지 마세요. 예를 들어 ASCS 노드를 애플리케이션 서버와 동일한 가용성 집합에 배치하면 안 됩니다.

근접 배치 그룹를 사용하는 경우 Azure 가용성 영역 내에서 Azure 가용성 집합을 배포할 수 있습니다.

네트워킹

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

NIC(네트워크 인터페이스 카드)

기존 온-프레미스 SAP 배포는 머신당 여러 NIC를 구현하여 비즈니스 트래픽에서 관리 트래픽을 분리합니다. Azure에서 VNet은 동일한 네트워크 패브릭을 통해 모든 트래픽을 전송하는 소프트웨어 정의 네트워크입니다. 따라서 성능을 위해 여러 개의 NIC를 사용할 필요가 없습니다. 그러나 조직에서 트래픽을 분리해야 하는 경우 가상 머신당 여러 개의 NIC를 배포하고, 각 NIC를 서로 다른 서브넷에 연결한 다음, NSG를 사용하여 서로 다른 액세스 제어 정책을 적용할 수 있습니다.

Azure NIC는 SAP note 962955설명된 대로 설치에 가상 호스트 이름을 사용하는 SAP 권장 사례를 지원하는 여러 IP를 지원합니다. (SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 있어야 합니다.)

서브넷 및 NSG

이 아키텍처는 VNet 주소 공간을 서브넷으로 세분화합니다. 각 서브넷은 서브넷에 대한 액세스 정책을 정의하는 NSG와 연결될 수 있습니다. 애플리케이션 서버를 별도의 서브넷에 배치하면 개별 서버 대신 서브넷 보안 정책을 관리하고, 이를 통해 더욱 간편하게 보안을 유지할 수 있습니다.

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

ExpressRoute Global Reach

네트워크 환경에 둘 이상의 ExpressRoute 회로가 포함된 경우 네트워크 홉을 줄이고 대기 시간을 줄이는 옵션은 ExpressRoute Global Reach사용하는 것입니다. 두 개의 ExpressRoute 라우팅 도메인을 브리징하기 위한 두 개 이상의 ExpressRoute 회로 간의 BGP(Border Gateway Protocol) 경로 피어링 설정입니다. 네트워크 트래픽이 하나 이상의 ExpressRoute 회로를 트래버스하며 현재 ExpressRoute 회로의 프라이빗 피어링에 대해서만 사용할 수 있는 경우 Global Reach가 대기 시간을 단축합니다.

현재는 ACL(네트워크 액세스 제어 목록) 또는 Global Reach에서 변경 가능한 다른 특성은 없습니다. 즉, 지정된 ExpressRoute 회로(온-프레미스 및 Azure)에서 학습된 모든 경로는 회로 피어링을 거쳐서 다른 ExpressRoute 회로에 보급됩니다. 리소스에 대한 액세스를 제한하기 위해 온-프레미스에서 네트워크 트래픽 필터링을 설정하는 것이 좋습니다.

ExpressRoute FastPath

MSEE(Microsoft Edge Exchange) v2라고도 하는 FastPath는 Azure 네트워크의 진입점에서 MSEE를 구현합니다. 대부분의 데이터 패킷에 대한 네트워크 홉을 줄입니다. FastPath는 네트워크 대기 시간을 낮추고 애플리케이션 성능을 향상하며 Azure에 대한 새로운 ExpressRoute 연결의 기본값입니다.

기존 ExpressRoute 회로의 경우 Azure 지원으로 FastPath를 활성화합니다.

FastPath는 VNet 피어링을 지원하지 않습니다. ExpressRoute에 연결된 것과 피어링된 다른 VNet이 있는 경우 온-프레미스 네트워크에서 다른 스포크 VNet으로 향하는 네트워크 트래픽이 VNet 게이트웨이로 계속 전송됩니다. 해결 방법은 모든 VNet을 ExpressRoute 회로에 직접 연결하는 것입니다.

부하 분산 장치

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

Azure Load Balancer 네트워크 전송 계층 서비스(계층 4)로, 원본 IP, 원본 포트, 대상 IP, 대상 포트 및 프로토콜 유형에 따라 데이터 스트림에서 5 튜플 해시로 트래픽을 분산합니다. 클러스터 설정에서 사용되어 기본 서비스 인스턴스 또는 장애 발생 시에는 정상 노드에 트래픽을 전달합니다. 모든 SAP 시나리오에 Azure 표준 Load Balancer 사용하는 것이 좋습니다. 표준 Load Balancer 기본적으로 안전하며 표준 Load Balancer 뒤에 있는 가상 머신이 아웃바운드 인터넷에 연결되지 않는다는 점을 강조해야 합니다. 가상 머신에서 아웃바운드 인터넷을 사용하도록 설정하려면 표준 Load Balancer 구성을 고려해야 합니다.

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

Azure Storage

일부 고객은 자신들의 애플리케이션 서버에 표준 스토리지를 사용합니다. SAP Note 1928533 명시된 대로 표준 관리 디스크는 지원되지 않으므로 모든 경우에 azure Managed Disks Premium 사용하는 것이 좋습니다. SAP note 2015553 대한 최신 업데이트는 몇 가지 특정 사용 사례에 대한 표준 HDD Storage 및 표준 SSD Storage 사용을 제외합니다.

애플리케이션 서버는 비즈니스 데이터를 호스트하지 않으므로 더 작은 P4 및 P6 Premium 디스크를 사용하여 비용을 최소화하고 중앙 SAP 스택 설치 시 단일 인스턴스 VM SLA를 활용할 수도 있습니다.

High-Availability 시나리오의 경우 Azure 공유 디스크는 Premium SSD에서 사용할 수 있으며 Azure Managed Disks 울트라 SSD. Azure 공유 디스크는 Windows Server, SUSE Enterprise Linux 15 SP 1 이상 또는 SAP용 SUSE Enterprise Linux와 함께 사용할 수 있습니다.

NFS 공유 시나리오의 경우 Azure NetApp Files /hana/shared, /hana/data 및 /hana/log 볼륨에 사용할 수 있는 네이티브 NFS 공유를 제공합니다. /hana/data 및 /hana/log 볼륨에 ANF 기반 NFS 공유를 사용하려면 v4.1 NFS 프로토콜을 사용해야 합니다. /hana/shared 볼륨의 경우 NFS 프로토콜 v3이 지원됩니다.

Azure Storage 클라우드 감시에서 클러스터가 상주하는 주 지역에서 멀리 떨어진 원격 Azure 지역의 디바이스로 쿼럼을 유지 관리하는 데도 사용됩니다.

백업 데이터 저장소의 경우 Azure 쿨 및 보관 액세스 계층을사용하는 것이 좋습니다. 이러한 스토리지 계층은 자주 액세스되지 않는 수명이 긴 데이터를 저장하는 비용 효율적인 방법입니다.

울트라 SSD는 디스크 대기 시간을 크게 줄이고 성능이 중요한 애플리케이션 및 SAP 데이터베이스 서버에 유용합니다.

성능 고려 사항

SAP 애플리케이션 서버는 데이터베이스 서버와 지속적으로 통신합니다. SAP HANA 비롯한 모든 데이터베이스 플랫폼에서 실행되는 성능이 중요한 애플리케이션의 경우 로그 볼륨에 WA(쓰기 가속기)를 사용하도록 설정하여 로그 쓰기 대기 시간을 개선합니다. WA는 M 시리즈 VM에 사용할 수 있습니다.

서버 간 통신을 최적화하려면 가속 네트워킹 을사용합니다. 이 옵션은 D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 및 Ms/Mms를 포함하여 지원되는 가상 머신에만 사용할 수 있습니다.

SAP HANA 성능 요구 사항에 대한 자세한 내용은 SAP note 1943937 - 하드웨어 구성 검사 도구(액세스에 필요한 SAP Service Marketplace 계정)를 참조하세요.

높은 IOPS 및 디스크 대역폭 처리량을 달성하기 위해 스토리지 볼륨 성능 최적화의 일반적인 사례가 Azure Storage 레이아웃에 적용됩니다. 예를 들어 여러 디스크를 결합하여 스트라이프 디스크 볼륨을 만들면 IO 성능이 향상됩니다. 자주 변경되지 않는 스토리지 콘텐츠에 읽기 캐시를 사용하면 데이터 검색 속도가 향상됩니다. SAP HANA 실행할 때 다양한 가상 머신 크기에 대한 스토리지 구성에 대한 권장 사항도 참조하세요.

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

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

SAP 애플리케이션 스택의 애플리케이션과 데이터베이스 계층 사이에 NVA(네트워크 가상 어플라이언스)를 배치하지 않는 것이 좋습니다. 이 경우 상당한 데이터 패킷 처리 시간이 도입되고 애플리케이션 성능이 저하될 수 있기 때문입니다.

또한 이 문서의 후반부에 설명된 대로 서비스 가용성을 향상시킬 수 있는 가용성 영역리소스를 배포할 때 성능을 고려하는 것이 좋습니다. 대상 지역의 모든 영역 간에 명확한 네트워크 대기 시간 프로필을 만드는 것이 좋습니다. 이렇게 하면 영역 간의 최소 대기 시간을 위한 리소스 배치를 결정할 수 있습니다. 이 프로필을 만들려면 각 영역에 작은 가상 머신을 배포하여 테스트를 실행합니다. 테스트에 권장되는 도구에는 PsPingIperf가포함됩니다. 테스트 후 이러한 가상 머신을 제거합니다. 공용 도메인 네트워크 대기 시간 테스트 도구도 편의상 사용할 수 있습니다.

확장성 고려 사항

SAP 애플리케이션 계층에서 Azure는 스케일 업 및 스케일 아웃을 위한 다양한 가상 머신 크기를 제공합니다. 포괄 목록은 SAP Note 1928533 - Azure의 SAP 애플리케이션: 지원되는 제품 및 Azure VM 유형(액세스에 필요한 SAP Service Marketplace 계정)을 참조하세요. 더 많은 가상 머신 유형을 계속 인증함에 따라 동일한 클라우드 배포에서 확장 또는 축소할 수 있습니다.

데이터베이스 계층에서 이 아키텍처는 한 인스턴스에서 최대 6테라바이트(TB)까지 확장할 수 있는 Azure 가상 머신에서 SAP HANA S/4 애플리케이션을 실행합니다. 워크로드가 최대 가상 머신 크기를 초과하는 경우 Microsoft는 12 TB RAM 한도를 훨씬 초과하는 옵션인 SAP HANA Azure 대규모 인스턴스를 제공합니다. 이러한 물리적 서버 중 Rev. 4는 Microsoft Azure 데이터 센터에 있으며 이 작성을 통해 단일 인스턴스에 대해 최대 24 TB의 메모리 용량을 제공합니다. 다중 노드 구성은 OLTP(온라인 트랜잭션 처리) 애플리케이션의 경우 최대 24TB, OLAP(온라인 분석 처리) 애플리케이션의 경우 60TB의 총 메모리 용량으로도 가능합니다.

가용성 고려 사항

리소스 중복성은 고가용성 인프라 솔루션의 일반적인 주제입니다. 덜 엄격한 SLA가 있는 기업의 경우 프리미엄 디스크가 있는 단일 인스턴스 Azure 가상 머신은 작동 시간 SLA를제공합니다. 중복 리소스가 가용성 집합에 배포되거나 가용성 영역 걸쳐 배포되면 서비스 가용성이 상승됩니다.

SAP 애플리케이션의 이러한 분산 설치에서는 고가용성을 달성하기 위해 기본 설치가 복제됩니다. 아키텍처의 각 계층마다 고가용성 설계가 다릅니다.

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

고가용성은 중복 Web Dispatcher 인스턴스를 통해 달성됩니다. SAP 설명서의 SAP Web Dispatcher를 참조하세요.

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

Azure Linux 가상 머신에서 Central Services의 고가용성을 위해 선택한 Linux 배포에 적합한 고가용성 확장이 사용되고 공유 파일 시스템은 SUSE DRDB 또는 Red Hat GlusterFS를 사용하여 고가용성 NFS 스토리지에 배치됩니다. Azure NetApp Files 사용하여 고가용성 NFS를 제공하여 NFS 클러스터에 대한 필요성을 없애고 SAP HANA 데이터 및 로그 파일을 호스트할 수 있으며, 이를 통해 대기 노드가 있는 HANA 스케일 아웃 배포 모델을 사용할 수 있습니다.

Azure NetApp Files SLES(SUSE Linux Enterprise Servers)에서 ASCS의 고가용성도 지원합니다. RHEL(Red Hat Enterprise Linux) HA의 ASCS에 대한 자세한 내용은 SIOS DataKeeper 정보를 참조하세요. 향상된 Azure Fence 에이전트는 SUSERed Hat 모두에 사용할 수 있으며 이전 버전의 에이전트에 비해 훨씬 더 빠른 서비스 장애 조치(failover)를 제공합니다.

다른 옵션은 Azure 공유 디스크를 사용하여 고가용성을 달성하는 것입니다. SUSE Enterprise Linux 15 SP 1 이상 또는 SAP용 SUSE Enterprise Linux에서 Pacemaker 클러스터는 Azure 공유 디스크를 사용하여 설정하여 고가용성을 달성할 수 있습니다.

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

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

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

애플리케이션 서버 풀 내에서 트래픽을 분산하여 고가용성을 얻습니다.

데이터베이스 계층

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

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

  • 자동 장애 조치의 경우 Linux 배포판용 HSR 및 Linux HAE(고가용성 확장)를 모두 사용합니다. Linux HAE는 HANA 리소스에 클러스터 서비스를 제공하여 장애 이벤트를 감지하고 잘못된 서비스를 정상 노드로 장애 조치하도록 오케스트레이션합니다.

  • 애플리케이션 서버 계층과 마찬가지로 일반적으로 배포되는 SLES용 HANA 고가용성 솔루션은 Pacemaker 및 RHEL용 SIOS LifeKeeper입니다.

가용성 영역 가상 머신 배포

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

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

가용성 영역 리소스를 배포하도록 결정할 때 다음과 같은 몇 가지 고려 사항이 적용됩니다.

  • 한 영역 내의 가상 머신 간 대기 시간.

  • 선택한 영역에서 가상 머신 간의 대기 시간

  • 선택한 영역에서 동일한 Azure 서비스(가상 머신 유형)를 사용할 수 있습니다.

참고

가용성 영역 고가용성을 지원하지만 효과적인 DR(재해 복구) 전략은 아닙니다. 영역 간 거리가 너무 가깝습니다. 일반적인 DR 지역은 주 지역에서 100마일 이상 떨어져 있어야 합니다.

활성/수동 배포 예제

이 배포 예제에서 활성/수동 상태는 영역 내의 애플리케이션 서비스 상태를 나타냅니다. 애플리케이션 계층에서 SAP 시스템의 4개 활성 애플리케이션 서버는 모두 영역 1에 있습니다. 네 개의 수동 애플리케이션 서버의 또 다른 집합은 영역 2에서 아직 종료되어 필요한 경우에만 활성화됩니다.

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

활성/활성 배포 예제

활성/활성 배포에서는 두 개의 영역에 걸쳐 두 개의 애플리케이션 서버 집합이 빌드됩니다. 각 영역 내에서 각 애플리케이션 서버 집합에 있는 두 개의 비활성(종료)입니다. 결과적으로 정상 작동의 두 영역에 활성 애플리케이션 서버가 있습니다.

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

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

재해 복구 고려 사항

SAP 애플리케이션 스택의 모든 계층은 다른 방법을 사용하여 DR 보호를 제공합니다.

애플리케이션 서버 계층

SAP 애플리케이션 서버에는 비즈니스 데이터가 포함되어 있지 않습니다. Azure에서 간단한 DR 전략은 보조 지역에 SAP 애플리케이션 서버를 만든 다음, 종료하는 것입니다. 주 애플리케이션 서버의 구성이 업데이트되거나 커널이 업데이트되는 즉시 동일한 변경 내용이 보조 지역의 가상 머신에 적용되어야 합니다. 예를 들어 SAP 커널 실행 파일을 DR 가상 머신에 복사합니다.

Azure Site Recovery 사용하여 다중 계층 SAP NetWeaver 애플리케이션 배포에 대한 DR을 설정할 수도 있습니다.

Central Services

이 SAP 애플리케이션 스택의 구성 요소도 비즈니스 데이터를 유지하지 않습니다. DR 지역에서 가상 머신을 빌드하여 Central Services 역할을 실행할 수 있습니다.

ASCS 전역 호스트 파일, 즉 /sapmnt 공유는 일반적으로 고가용성 NFS 클러스터 또는 Azure NetApp Files제공됩니다. 이 콘텐츠를 보호하려면 DR SAP 시스템에 /sapmnt 공유를 제공하는 원격 파일 서비스(NFS 또는 Azure NetApp Files)에 복사합니다. Rsync 또는 신뢰할 수 있는 파일 복사 도구를 사용합니다.

Azure Site Recovery iSCSI 대상으로 만든 STONITH 디바이스의 복제를 지원합니다.

Central Services 서버의 두 운영 체제 드라이브를 DR 지역에 복제하려면 Azure Site Recovery 사용할 수 있습니다.

단계별 지침은 Azure Site Recovery 사용하여 SAP용 재해 복구 솔루션빌드를 참조하세요.

데이터베이스 계층

HANA 지원 복제에 HSR을 사용합니다. HSR은 로컬 2개 노드 고가용성 설정 외에도 별도의 Azure 지역에 있는 세 번째 노드가 클러스터에 속하지 않은 외부 엔터티의 역할을 하고, 클러스터된 HSR 쌍의 보조 복제본에 복제 대상으로 등록하는 다중 계층 복제를 지원합니다. 이렇게 하면 복제 데이지 체인이 만들어집니다.

DR 노드로의 장애 조치는 수동 프로세스입니다. HANA 2.0 SPS 03부터 DR 지역의 주 노드를 비동기적으로 복제하여추가 복제본을 지원하는 다중 대상 시스템 복제 를 구성할 수 있습니다. 또한 Central Services 또는 HANA 데이터베이스 계층에 Azure NetApp Files 사용하는 경우 rsync 또는 선택한 콘텐츠 복제 도구를 사용합니다.

공유 서비스에 대한 DR

관리 jumpbox, 클라우드 기반 디렉터리 서비스, 백업 및 모니터링 서비스와 같은 배포된 모든 클라우드 자산에서 많은 IT 서비스를 공유합니다. 서비스가 제공하는 모든 것을 사용하여 공유 서비스를 DR 지역에 복제합니다.

Azure Site Recovery를 사용 하는 자동화 된 DR

Azure Site Recovery를 사용 하 여 원래 구성의 완전히 복제 된 프로덕션 사이트를 자동으로 작성 하려면 사용자 지정 배포 스크립트를 실행 해야 합니다. 예를 들어 Site Recovery는 먼저 가용성 집합에서 Vm을 배포한 다음 사용자 지정 스크립트를 실행 하 여 이미 백 엔드 풀을 정의한 기존 (미리 작성 된) 부하 분산 장치를 장애 조치 (failover) 가상 머신의 NIC에 연결 합니다. 사용자 지정 Site Recovery 자동화 Runbook 스크립트의 예는 GitHub에서 사용할 수 있습니다.

참고

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

비용 고려 사항

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

자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

가상 머신

이 아키텍처는 응용 프로그램 계층 및 데이터베이스 계층에 대해 Linux를 실행 하는 가상 컴퓨터를 사용 합니다. sap NetWeaver 계층은 Windows 가상 컴퓨터를 사용 하 여 sap 서비스 및 응용 프로그램을 실행 합니다. 데이터베이스 계층은 anydb를 데이터베이스로 실행 합니다 (예: Microsoft SQL Server, Oracle 또는 IBM DB2). 가상 머신은 관리를 위한 점프 상자로도 사용 됩니다.

가상 컴퓨터에 대 한 몇 가지 결제 옵션은 다음과 같습니다.

완료 시간 또는 리소스 소비를 예측할 수 없는 작업의 경우에는 종 량 제 옵션을 고려 하세요.

1 년 또는 3 년 동안 가상 컴퓨터를 사용 하 여 커밋할 수 있는 경우 Azure Reservations 를 사용 하는 것이 좋습니다. VM 예약은 종 량 제 가격과 비교 하 여 최대 72%까지 비용을 절감할 수 있습니다.

Azure 스폿 vm 을 사용 하 여 중단 될 수 있는 워크 로드를 실행 하 고 미리 결정 된 기간이 나 SLA 내에서 완료 하지 않아도 됩니다. Azure는 사용 가능한 용량이 있는 경우 Azure에서 Vm을 배포 하 고 용량이 다시 필요한 경우에는 임의로 합니다. 별색 가상 머신과 관련 된 비용이 크게 줄어듭니다. 이러한 워크 로드에 대 한 Vm을 고려 합니다.

  • 고성능 컴퓨팅 시나리오, 일괄 처리 작업 또는 시각적 렌더링 응용 프로그램입니다.
  • 연속 통합 및 지속적인 업데이트 작업을 비롯 한 테스트 환경.
  • 대규모 상태 비저장 응용 프로그램.

자세한 내용은 가격 책정을 Linux Virtual Machines.

가상 컴퓨터 및 가용성 집합

모든 풀 및 클러스터 (웹 디스패처, SAP 응용 프로그램 서버, 중앙 서비스 및 HANA)에 대해 가상 컴퓨터는 별도의 가용성 집합으로 그룹화 됩니다. 가용성 집합에 대 한 비용은 없습니다. 만든 각 VM 인스턴스에만 요금을 지불 합니다.

Azure Load Balancer

이 시나리오에서 Azure 부하 분산 장치는 응용 프로그램 계층 서브넷의 가상 컴퓨터에 트래픽을 분산 하는 데 사용 됩니다.

구성 된 부하 분산 및 아웃 바운드 규칙의 수에 대해서만 요금이 청구 됩니다. 인바운드 NAT 규칙은 무료입니다. 규칙이 구성 되지 않은 경우에는 표준 Load Balancer에 대 한 시간당 요금이 청구 되지 않습니다.

Azure ExpressRoute

이 아키텍처에서 Azure Express 경로는 온-프레미스 네트워크와 Azure 가상 네트워크 간의 개인 연결을 만드는 데 사용 되는 네트워킹 서비스입니다.

모든 인바운드 데이터 전송은 무료입니다. 모든 아웃 바운드 데이터 전송은 미리 결정 된 요금을 기준으로 요금이 청구 됩니다. 자세한 정보는 Azure express 경로 가격 을 참조 하세요.

관리 및 운영 고려 사항

Backup

SAP HANA 데이터는 여러 가지 방법으로 백업할 수 있습니다. Azure로 마이그레이션한 후에는 이미 있는 기존 백업 솔루션을 계속 사용 합니다. Azure는 백업에 대 한 두 가지 기본적인 방법을 제공 합니다. 가상 컴퓨터에서 SAP HANA를 백업 하 고 파일 수준에서 Azure Backup을 사용할 수 있습니다. Azure Backup은 이제 SAP에서 인증 된 Backint 입니다. AZURE BACKUP FAQ도 참조 하세요.

참고

이 문서를 작성할 당시 HANA 단일 컨테이너 배포만 Azure storage 스냅숏을 지원 합니다.

ID 관리

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

  • Azure RBAC (역할 기반 액세스 제어)를 통해 azure 리소스에 대 한 액세스를 제공 합니다.

  • LDAP, Azure Active Directory, Kerberos 또는 다른 시스템을 통해 Azure virtual machines에 대 한 액세스 권한을 부여 합니다.

  • SAP에서 제공 하는 서비스를 통해 앱 자체 내에서 액세스를 지원 하거나 OAuth 2.0 및 Azure Active Directory을 사용 합니다.

모니터링

응용 프로그램 및 서비스의 가용성과 성능을 최대화 하기 위해 클라우드 및 온-프레미스 환경에서 원격 분석을 수집, 분석 및 작동 하는 포괄적인 솔루션인 Azure Monitor를 사용 합니다. Azure Monitor는 응용 프로그램의 작동 방식을 보여 주며, 이러한 문제에 영향을 주는 문제 및 해당 하는 리소스를 사전에 식별 합니다.

SAP 인프라의 리소스 및 서비스 성능에 대한 SAP 기반 모니터링을 제공하기 위해 Azure SAP 고급 모니터링 확장을 사용합니다. 이 확장은 SAP 애플리케이션에 운영 체제 모니터링 및 DBA Cockpit 함수에 대한 Azure 모니터링 통계를 제공합니다. SAP 고급 모니터링은 Azure에서 SAP를 실행하기 위한 필수 구성 요소입니다. 자세한 내용은 Sap Note 2191498 – "Azure를 사용 하는 Linux의 Sap: 향상 된 모니터링"을 참조 하세요. (액세스 하는 데 필요한 SAP 서비스 마켓플레이스 계정)

보안 고려 사항

Sap에는 SAP 응용 프로그램 및 데이터베이스 내에서 역할 기반 액세스 및 권한 부여를 제어 하는 자체 사용자 관리 엔진 (UME)이 있습니다. 자세한 내용은 SAP HANA 보안: 개요를 참조 하세요.

네트워크 보안을 강화 하려면 네트워크 가상 어플라이언스를 사용 하 여 웹 디스패처 및 Fiori Front-End 서버 풀에 대 한 서브넷 앞에 방화벽을 만드는 네트워크 DMZ를 구현 하는 것이 좋습니다.

인프라 보안을 위해 전송 중 데이터와 미사용 데이터가 암호화됩니다. SAP NetWeaver에 대한 Azure Virtual Machines 계획 및 구현 가이드의 "보안 고려 사항" 섹션에서 네트워크 보안 처리를 다루고 있으며, 이는 S/4HANA에 적용됩니다. 이 가이드에서는 애플리케이션 통신을 허용하기 위해 방화벽에서 열어야 하는 네트워크 포트도 지정합니다.

Linux 가상 머신 디스크를 암호화 하려면 Azure Disk Encryption를 사용할 수 있습니다. Linux의 DM-Crypt 기능을 사용하여 운영 체제 및 데이터 디스크에 대한 볼륨 암호화를 제공합니다. 또한 이 솔루션은 Azure Key Vault와 함께 작동하여 키 자격 증명 모음 구독에서 디스크 암호화 키와 비밀을 제어하고 관리할 수 있습니다. 가상 머신 디스크의 데이터는 미사용 시 Azure Storage에 암호화됩니다.

SAP HANA 미사용 데이터 암호화의 경우 SAP HANA 네이티브 암호화 기술을 사용하는 것이 좋습니다.

참고

동일한 저장소 볼륨에서 Azure Disk Encryption에 대 한 HANA 데이터 미사용 암호화를 사용 하지 마세요. HANA의 경우 HANA 데이터 암호화만 사용합니다. 또한 Linux 가상 머신에 대 한 운영 체제 부팅 디스크는 Azure Disk Encryption을 지원 하지 않으며 Linux에서 Azure Disk Encryption 연결 된 데이터 디스크를 지원 Azure Site Recovery 않습니다.

커뮤니티

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

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