Azure의 Windows에서 SAP NetWeaver 실행

이 가이드는 고가용성으로 Azure의 Windows 환경에서 SAP NetWeaver를 실행하기 위한 일련의 검증된 사례를 제시합니다. 데이터베이스는 AnyDB로, SAP HANA 외에 지원하는 모든 DBMS(데이터베이스 관리 시스템)를 나타내는 SAP 용어입니다.

아키텍처

다음 다이어그램은 가용성 집합 시나리오에서 Windows 환경의 SAP NetWeaver를 보여 줍니다. 이 아키텍처는 성능 향상을 위해 공유 파일 계층 및 근접 배치 그룹에 Azure NetApp Files를 사용합니다.

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

다음 다이어그램은 Windows 환경의 SAP NetWeaver를 보여 줍니다. 가용성 영역은 다음과 같이 복원력 향상에 사용됩니다.

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

이 가이드는 프로덕션 시스템에 대해 설명합니다. 컴퓨터는 조직의 요구 사항을 수용하기 위해 변경할 수 있는 특정 VM(가상 머신) 크기로 배포됩니다. 시스템을 단일 VM으로 줄일 수 있습니다. 이 가이드에서는 아키텍처 원칙을 설명하기 위해 네트워크 레이아웃을 크게 단순화했습니다. 엔터프라이즈 네트워크 전체를 설명하기 위한 것은 아닙니다.

워크플로

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

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

VM. 이 아키텍처는 다음과 같은 방식으로 그룹화된 애플리케이션 계층 및 데이터베이스 계층에 VM을 사용합니다.

• SAP NetWeaver. 애플리케이션 계층은 Windows VM을 사용하여 SAP 중앙 서비스 및 SAP 애플리케이션 서버를 실행합니다. 고가용성을 위해 중앙 서비스를 실행하는 VM은 Windows 서버 장애 조치(failover) 클러스터로 구성됩니다. 이러한 가상 머신은 Azure 파일 공유 또는 Azure 공유 디스크에서 지원됩니다.

• AnyDB. 데이터베이스 계층은 Microsoft SQL Server, Oracle 또는 IBM Db2일 수 있는 AnyDB를 데이터베이스로 실행합니다.

• 점프 상자/베스천 호스트. 관리자는 점프 상자 또는 베스천 호스트라고 하는 보안이 강화된 VM을 사용하여 다른 VM에 연결합니다. 일반적으로 도메인 컨트롤러나 백업 서비스 같은 공유 서비스에 포함됩니다. SSH(Secure Shell Protocol) 및 RDP(원격 데스크톱 프로토콜)가 서버 관리에 사용되는 유일한 서비스인 경우 Azure Bastion 호스트가 대안입니다. SQL Server Management Studio 또는 SAP Front End와 같은 다른 관리 도구를 사용하는 경우 기존의 자체 배포 점프 상자를 사용하세요.

• Windows Server Active Directory 도메인 컨트롤러. 도메인 컨트롤러는 도메인에 있는 모든 VM 및 사용자의 ID 관리에 사용됩니다.

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

부하 분산 장치. 부하 분산 장치는 애플리케이션 계층 서브넷의 VM에 트래픽을 분산하는 데 사용됩니다. SAP 애플리케이션 고가용성을 위해 기본 제공된 SAP Web Dispatcher, Azure Load Balancer 또는 네트워크 어플라이언스를 사용합니다. 트래픽 유형(예: HTTP 또는 SAP GUI) 또는 필수 네트워크 서비스(예: SSL(Secure Sockets Layer) 종료)에 따라 적절하게 선택하면 됩니다. SAP의 영역 배포에 Load Balancer를 통합하는 경우 기본 SKU 분산 장치에는 영역 중복이 제공되지 않으므로 표준 Load Balancer를 선택해야 합니다.

일부 인터넷 연결 인바운드/아웃바운드 디자인 예는 Azure의 SAP에 대한 인바운드 및 아웃바운드 인터넷 연결을 참조하세요.

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

• ABAP(Advanced Business Application Programming) ASCS(SAP Central Service)
• ERS(입고 기준 자동 정산)

서비스는 부하 분산 장치를 공유하여 솔루션을 단순화할 수 있습니다.

표준 SKU는 SID(다중 보안 식별자) SAP 클러스터도 지원합니다. 즉, Windows의 여러 SAP 시스템은 공통 고가용성 인프라를 공유하여 비용을 절감할 수 있습니다. 비용 절감을 평가하고 하나의 클러스터에 너무 많은 시스템을 배치하지 마세요. Azure는 클러스터당 5개 이하의 SID를 지원합니다.

애플리케이션 게이트웨이 Azure Application Gateway는 웹 애플리케이션에 대한 트래픽을 관리하는 데 사용할 수 있는 웹 트래픽 부하 분산 장치입니다. 기존 부하 분산 장치는 전송 계층(OSI 계층 4 - TCP 및 UDP)에서 작동합니다. 원본 IP 주소와 포트를 기반으로 트래픽을 대상 IP 주소와 포트로 라우팅합니다. Application Gateway는 URI 경로 또는 호스트 헤더와 같은 HTTP 요청의 추가 특성을 기반으로 라우팅 결정을 내릴 수 있습니다. 이 유형의 라우팅은 애플리케이션 계층(OSI 계층 7) 부하 분산이라고 합니다.

가용성 집합. 모든 풀 및 클러스터(Web Dispatcher, SAP 애플리케이션 서버, Central Services 및 데이터베이스)의 VM은 별도의 가용성 집합으로 그룹화됩니다. 역할당 2개 이상의 VM이 프로비전됩니다. 가용성 집합은 애플리케이션 및 VM의 가용성을 높입니다. 이렇게 하기 위해 역할 인스턴스를 여러 호스트에 분산하여 호스트 시스템 오류 또는 유지 관리 이벤트를 관리합니다. 대안은 이 문서의 뒷부분에 설명된 대로 가용성 영역을 사용하여 워크로드 가용성을 개선하는 것입니다.

영역 중복 게이트웨이. Azure ExpressRoute 또는 VPN 게이트웨이를 영역 간에 배포하여 영역 오류로부터 보호할 수 있습니다. 영역 배포와 영역 중복 배포 간의 차이점을 이해하려면 영역 중복 가상 네트워크 게이트웨이를 참조하세요. 사용되는 IP 주소는 게이트웨이의 영역 배포를 위해 표준 SKU여야 합니다.

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

네트워크 보안 그룹. 가상 네트워크에서 들어오는 트래픽, 나가는 트래픽 및 서브넷 간 트래픽을 제한하려면 네트워크 보안 그룹을 만듭니다.

애플리케이션 보안 그룹. 애플리케이션 중심의 세분화된 워크로드 기반 네트워크 보안 정책을 정의하려면 명시적 IP 주소 대신 애플리케이션 보안 그룹을 사용합니다. 애플리케이션 보안 그룹은 VM을 이름별로 그룹화하는 방법을 제공하고 네트워크의 신뢰할 수 있는 세그먼트에서 트래픽을 필터링하여 애플리케이션을 보호하는 데 도움을 줍니다.

게이트웨이 게이트웨이는 고유한 네트워크를 연결하여 온-프레미스 네트워크를 Azure 가상 머신으로 확장합니다. ExpressRoute를 사용하여 공용 인터넷을 통해 이동하지 않는 프라이빗 연결을 만드는 것이 좋지만, 사이트 간 연결을 사용할 수도 있습니다. 대기 시간을 줄이거나 처리량을 늘리려면 이 문서의 뒷부분에서 설명하는 대로 ExpressRoute Global Reach 및 ExpressRoute FastPath를 고려해 보세요.

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

권장 사항

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

VM

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

Azure VM 형식 및 처리량 메트릭(SAPS)에 대한 SAP 지원에 대한 자세한 내용은 SAP 노트 1928533을 참조하세요. SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다.

SAP Web Dispatcher

Web Dispatcher 구성 요소는 SAP 애플리케이션 서버 간에 SAP 트래픽 부하 분산에 사용됩니다. Web Dispatcher 구성 요소의 고가용성을 달성하기 위해 Load Balancer는 Web Dispatcher 인스턴스의 장애 조치(failover) 클러스터 또는 병렬 Web Dispatcher 설정을 구현하는 데 사용됩니다. 솔루션에 대한 자세한 설명은 SAP Web Dispatcher의 고가용성을 참조하세요.

애플리케이션 서버 풀

SAP SMLG 트랜잭션은 ABAP 애플리케이션 서버의 로그온 그룹을 관리하고 로그온 사용자의 부하를 분산하는 데 주로 사용됩니다. 일괄 처리 서버 그룹용 SM61 및 RFC(원격 함수 호출) 그룹용 RZ12와 같은 기타 트랜잭션도 로그온 사용자의 부하를 분산합니다. 이러한 트랜잭션은 SAP Central Services의 메시지 서버 내에서 부하 분산 기능을 사용하여 들어오는 세션 또는 워크로드를 SAP GUI 및 RFC 트래픽에 대한 SAP 애플리케이션 서버 풀 간에 분산합니다.

SAP Central Services 클러스터

이 아키텍처는 애플리케이션 계층의 VM에서 중앙 서비스를 실행합니다. Central Services는 단일 VM에 배포할 때 잠재적인 SPOF(단일 실패 지점)입니다. 고가용성 솔루션을 구현하려면 파일 공유 클러스터 또는 공유 디스크 클러스터를 사용합니다.

고가용성 파일 공유를 구현하려는 경우 여러 가지 옵션이 있습니다. Azure Files 공유를 완전 관리형 클라우드 기반 SMB(서버 메시지 블록) 또는 NFS(네트워크 파일 시스템) 공유로 사용하는 것이 좋습니다. Azure Files 대신 고성능 NFS 및 SMB 공유를 제공하는 Azure NetApp Files를 사용해도 됩니다.

또한 Azure Files와 함께 Windows 서버 장애 조치(failover) 클러스터를 사용하여 중앙 서비스 인스턴스에서 고가용성 파일 공유를 구현할 수 있습니다. 또한 이 솔루션은 Azure 공유 디스크를 클러스터 공유 볼륨으로 사용하여 공유 디스크가 있는 Windows 클러스터를 지원합니다. 공유 디스크를 선호하는 경우 Azure 공유 디스크를 사용하여 SAP Central Services 클러스터용 Windows Server 장애 조치(failover) 클러스터를 설정하는 것이 좋습니다.

SIOS Technology Corp의 SIOS DataKeeper Cluster Edition과 같은 파트너 제품도 있습니다. 이 추가 기능은 ASCS 클러스터 노드에 연결된 독립 디스크의 콘텐츠를 복제한 다음 디스크를 클러스터 소프트웨어에 클러스터 공유 볼륨으로 제공합니다.

클러스터 네트워크 분할에서 클러스터 소프트웨어는 쿼럼 응답을 사용하여 조각난 클러스터의 두뇌 역할을 할 네트워크 세그먼트와 관련 서비스를 선택합니다. Windows는 많은 쿼럼 모델을 제공합니다. 이 솔루션은 더 간단하고 컴퓨팅 노드 감시보다 더 높은 가용성을 제공하는 Cloud Witness를 사용합니다. Azure 파일 공유 감시는 클러스터 쿼럼 응답을 제공하기 위한 또 다른 대안입니다.

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

가용성 집합

가용성 집합은 서버를 다양한 물리적 인프라에 분산하고 그룹을 업데이트하여 서비스 가용성을 높입니다. SLA(서비스 수준 계약)를 충족하려면 동일한 역할을 수행하는 VM을 동일한 가용성 집합에 배치합니다. 이렇게 하면 Azure 인프라 유지 관리 또는 하드웨어 오류로 인한 계획된 가동 중지 시간과 계획되지 않은 가동 중지 시간을 방지할 수 있습니다. 더 높은 SLA를 충족하려면 가용성 집합당 2개 이상의 VM이 있어야 합니다.

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

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

네트워킹

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

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

NIC는 가상 네트워크에서 VM 간의 모든 통신을 가능하게 합니다. 기존 온-프레미스 SAP 배포는 머신당 여러 NIC를 구현하여 비즈니스 트래픽에서 관리 트래픽을 분리합니다.

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

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

서브넷 및 네트워크 보안 그룹

이 아키텍처는 가상 네트워크 주소 공간을 서브넷으로 세분화합니다. 각 서브넷을 서브넷의 액세스 정책을 정의하는 네트워크 보안 그룹과 결할 수 있습니다. 별도의 서브넷에 애플리케이션 서버를 배치합니다. 이렇게 하면 개별 서버가 아닌 서브넷 보안 정책을 관리하여 보다 쉽게 보안을 유지할 수 있습니다.

네트워크 보안 그룹을 서브넷과 연결하면 네트워크 보안 그룹이 서브넷 내의 모든 서버에 적용되고 서버에 대한 세분화된 제어를 제공합니다. Azure Portal, PowerShell 또는 Azure CLI를 사용하여 네트워크 보안 그룹을 설정합니다.

ExpressRoute Global Reach

네트워크 환경에 둘 이상의 ExpressRoute 연결이 있는 경우 ExpressRoute Global Reach를 사용하면 네트워크 홉 및 대기 시간을 줄이는 데 도움이 될 수 있습니다. 이 기술은 2개의 ExpressRoute 라우팅 도메인을 연결하기 위해 2개 이상의 ExpressRoute 연결 간에 설정되는 BGP(Border Gateway Protocol) 경로 피어링입니다. Global Reach는 네트워크 트래픽이 2개 이상의 ExpressRoute 연결을 트래버스할 때 대기 시간을 줄입니다. 지금은 ExpressRoute 회로의 개인 피어링에만 사용할 수 있습니다.

현재 Global Reach에서 변경할 수 있는 네트워크 액세스 제어 목록 또는 기타 특성이 없습니다. 따라서 온-프레미스 및 Azure의 특정 ExpressRoute 회로에서 학습한 모든 경로는 회로 피어링을 통해 다른 ExpressRoute 회로로 보급됩니다. 리소스에 대한 액세스를 제한하려면 온-프레미스에서 네트워크 트래픽 필터링을 설정하는 것이 좋습니다.

ExpressRoute FastPath

MSEE(Microsoft Edge Exchange) v2라고도 하는 FastPath는 Azure 네트워크의 진입점에서 MSEE를 구현합니다. FastPath는 대부분의 데이터 패킷에 대한 네트워크 홉을 줄입니다.

Azure에 대한 모든 새 ExpressRoute 연결의 기본 구성은 FastPath입니다. 기존 ExpressRoute 회로의 경우 Azure 지원에 문의하여 FastPath를 활성화하세요.

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

부하 분산 장치

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

Load Balancer는 데이터 스트림의 5튜플 해시를 사용하여 트래픽을 균등하게 분산하는 네트워크 전송 계층 서비스(계층 4)입니다. 해시는 원본 IP, 원본 포트, 대상 IP, 대상 포트 및 프로토콜 형식을 기반으로 합니다. Azure의 SAP 배포에서 Load Balancer는 기본 서비스 인스턴스 또는 결함이 있는 경우 정상적인 노드로 트래픽을 전달하기 위해 클러스터 설정에서 사용됩니다.

모든 SAP 시나리오에 대해 표준 Load Balancer를 사용하는 것이 좋습니다. 백 엔드 풀의 VM에 공용 아웃바운드 연결이 필요하거나 Azure 영역 배포에서 사용되는 경우 표준 Load Balancer는 기본적으로 안전하므로 추가 구성이 필요합니다. 명시적으로 구성하지 않는 한 아웃바운드 연결을 허용하지 않습니다.

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

스토리지

일부 고객은 애플리케이션 서버에 표준 스토리지를 사용합니다. 표준 관리 디스크는 지원되지 않습니다. SAP 노트 1928533을 참조하세요. SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다. 모든 경우에 프리미엄 Azure 관리 디스크를 사용하는 것이 좋습니다. 최신 SAP 노트 2015553 업데이트에 따르면 특정 사용 사례에 표준 HDD 스토리지 및 표준 SSD 스토리지를 사용할 수 없도록 제외되었습니다.

애플리케이션 서버는 비즈니스 데이터를 호스트하지 않습니다. 따라서 더 작은 P4 및 P6 프리미엄 디스크를 사용하여 비용을 줄일 수 있습니다. 이렇게 하면 중앙 SAP 스택 설치가 있는 경우 단일 인스턴스 VM SLA의 이점을 누릴 수 있습니다.

고가용성 시나리오의 경우 Azure 파일 공유 및 Azure 공유 디스크를 사용할 수 있습니다. Azure 프리미엄 SSD 관리 디스크 및 Azure Ultra Disk Storage는 Azure 공유 디스크에 사용할 수 있으며 프리미엄 SSD는 Azure 파일 공유에 사용할 수 있습니다.

또한 Storage는 클라우드 감시에서 클러스터가 있는 주 지역에서 떨어져 있는 원격 Azure 지역의 디바이스에서 쿼럼을 유지하는 데도 사용됩니다.

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

Ultra Disk Storage는 디스크 대기 시간을 크게 줄입니다. 결과적으로 SAP 데이터베이스 서버와 같이 성능이 중요한 애플리케이션에 도움이 됩니다. Azure의 블록 스토리지 옵션을 비교하려면 Azure 관리 디스크 형식을 참조하세요.

고가용성 고성능 공유 데이터의 저장에는 Azure NetApp Files를 사용합니다. 이 기술은 Oracle을 사용할 때와 애플리케이션 데이터를 호스트할 때 데이터베이스 계층에 특히 유용합니다.

성능 고려 사항

SAP 애플리케이션 서버는 데이터베이스 서버와 지속적으로 통신합니다. 데이터베이스 플랫폼에서 실행되는 성능이 중요한 애플리케이션의 경우 로그 볼륨에 쓰기 가속기를 사용하도록 설정합니다. 그러면 로그 쓰기 대기 시간이 향상될 수 있습니다. 쓰기 가속기는 M 시리즈 VM에 사용할 수 있습니다. 서버 간 통신을 최적화하려면 가속화된 네트워킹을 사용합니다. 가속화된 네트워킹은 D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 및 Ms/Mms를 포함하여 지원되는 VM 시리즈에만 사용할 수 있습니다. 자세한 내용은 가속화된 네트워킹을 사용하여 VM 성능 최대화를 참조하세요.

높은 IOPS 및 디스크 처리량을 달성하려면 Azure Storage 레이아웃에 적용되는 스토리지 볼륨 성능 최적화의 일반적인 방법을 따릅니다. 예를 들어, I/O 성능을 개선시키기 위해 여러 디스크를 함께 배치하여 스트라이프 디스크 볼륨을 만들 수 있습니다. 자주 변경되지 않는 스토리지 콘텐츠에 읽기 캐시를 사용하면 데이터 검색 속도가 향상됩니다.

이제 Ultra Disk Storage를 I/O 집약적인 애플리케이션에 사용할 수 있습니다. 이러한 디스크를 사용할 수 있는 경우 쓰기 가속기 프리미엄 스토리지보다 디스크를 사용하는 것이 좋습니다. 다시 부팅하지 않고도 IOPS 및 MB/s와 같은 성능 메트릭을 개별적으로 늘리거나 줄일 수 있습니다.

SQL Server에서 SAP 워크로드에 맞게 Azure Storage를 최적화하는 방법에 대한 탁월한 조언은 SAP NetWeaver용 Azure Virtual Machines 계획 및 구현을 참조하세요.

애플리케이션과 SAP 애플리케이션 스택의 데이터베이스 계층 사이에 NVA(네트워크 가상 어플라이언스)를 배치하지 않는 것이 좋습니다. 이렇게 하면 데이터 패킷을 처리하는 시간이 크게 증가하므로 애플리케이션 성능이 허용할 수 없을 만큼 저하됩니다.

근접 배치 그룹

일부 SAP 애플리케이션은 데이터베이스와 자주 통신해야 합니다. 애플리케이션 계층과 데이터베이스 계층의 물리적 근접도는 네트워크 대기 시간에 영향을 주며, 애플리케이션 성능에 악영향을 줄 수 있습니다.

네트워크 대기 시간을 최적화하기 위해 가용성 집합에 배포된 VM에 대한 논리적 제약 조건을 설정하는 근접 배치 그룹을 사용할 수 있습니다. 근접 배치 그룹은 확장성, 가용성 또는 비용보다 공동 배치 및 성능을 우선합니다. 대부분의 SAP 애플리케이션의 사용자 환경을 크게 개선시킬 수 있습니다. AzureCAT SAP 배포 팀의 GitHub에서 사용할 수 있는 스크립트는 스크립트를 참조하세요.

가용성 영역

가용성 영역은 특정 Azure 지역 내에서 실제로 분리된 위치인 영역 전체에 VM을 배포하는 방법을 제공합니다. 해당 목적은 서비스 가용성을 향상시키는 것입니다. 그러나 여러 영역에 걸쳐 리소스를 배포하면 대기 시간이 늘어날 수 있으므로 성능 고려 사항을 염두에 두세요.

관리자는 영역 간 대기 시간을 최소화하는 리소스 배치를 결정하려면 대상 지역의 모든 영역 간 네트워크 대기 시간을 명확히 알 수 있는 프로필이 필요합니다. 이 프로필을 만들려면 테스트를 위해 각 영역에 작은 VM을 배포합니다. 이러한 테스트에 권장되는 도구는 PsPing 및 Iperf입니다. 테스트가 완료되면 테스트에 사용한 VM을 제거합니다. 대안으로 Azure 영역 간 대기 시간 확인 도구를 사용하는 것이 좋습니다.

확장성 고려 사항

SAP 애플리케이션 계층의 경우 Azure는 스케일 업 및 스케일 아웃을 위한 다양한 VM 크기를 제공합니다. 전체 목록은 SAP 노트 1928533 - Azure의 SAP 애플리케이션: 지원되는 제품 및 Azure VM 유형을 참조하세요. SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다.

SAP 애플리케이션 서버 및 Central Services 클러스터를 스케일 업 및 스케일 다운할 수 있습니다. 사용하는 인스턴스 수를 변경하여 스케일 아웃 및 스케일 인할 수도 있습니다. AnyDB 데이터베이스는 스케일 업 및 다운할 수 있지만 확장되지는 않습니다. AnyDB용 SAP 데이터베이스 컨테이너는 분할을 지원하지 않습니다.

가용성 고려 사항

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

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

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

Web Dispatcher 구성 요소가 SAP 애플리케이션 서버 간의 SAP 트래픽을 위한 부하 분산 장치로 사용됩니다. SAP Web Dispatcher의 고가용성을 달성하기 위해 Load Balancer는 장애 조치(failover) 클러스터 또는 병렬 Web Dispatcher 설정을 구현합니다.

인터넷 연결 통신의 경우 보안 문제를 해결하기 위해 경계 네트워크(DMZ라고도 함)에서 독립 실행형 솔루션을 사용하는 것이 좋습니다.

ASCS의 Embedded Web Dispatcher는 특별한 옵션입니다. 이 옵션을 사용하는 경우 ASCS의 추가 워크로드 때문에 적절한 크기 조정을 고려합니다.

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

중앙 서비스의 고가용성은 Windows 서버 장애 조치(failover) 클러스터로 구현됩니다. 장애 조치(failover) 클러스터에 대한 클러스터 스토리지가 Azure에 배포되면 클러스터형 공유 디스크 또는 클러스터형 파일 공유라는 두 가지 방법으로 구성할 수 있습니다.

• Azure Files를 완전 관리형 클라우드 네이티브 SMB 또는 NFS 공유로 사용하는 것이 좋습니다. 또 다른 방법은 고성능 엔터프라이즈급 NFS 및 SMB 공유를 제공하는 Azure NetApp Files를 사용하는 것입니다.

• Azure에서 공유 디스크를 사용하여 클러스터를 설정하는 두 가지 방법이 있습니다. 첫째, Azure 공유 디스크를 사용하여 SAP Central Services용 Windows Server 장애 조치(failover) 클러스터를 설정하는 것이 좋습니다. 구현 예는 Azure 공유 디스크를 사용하는 ASCS 클러스터를 참조하세요. 클러스터형 공유 디스크를 구현하는 또 다른 방법은 SIOS DataKeeper를 사용하여 다음 작업을 수행하는 것입니다.

  • 클러스터 노드에 연결된 독립 디스크의 콘텐츠를 복제합니다.
  • 드라이브를 클러스터 관리자의 클러스터 공유 볼륨으로 추상화합니다.

  구현에 대한 자세한 내용은 Azure에서 SIOS를 사용하여 SAP ASCS 클러스터링을 참조하세요.

표준 Load Balancer가 도입되었기 때문에 고가용성 포트를 사용할 수 있습니다. 이렇게 하면 많은 SAP 포트에 대한 부하 분산 규칙을 구성하지 않아도 됩니다. 또한 온-프레미스 또는 Azure에서 부하 분산 장치를 설정할 때 부동 IP 또는 DSR이라고도 하는 DSR(Direct Server Return) 기능을 사용하도록 설정합니다. 그렇게 하면 서버 응답이 부하 분산 장치를 무시할 수 있는 방법이 제공됩니다. 이렇게 직접 연결하면 데이터 전송 경로에서 부하 분산 장치의 병목 상태가 방지됩니다. ASCS 및 데이터베이스 클러스터의 경우 DSR을 사용하도록 설정하는 것이 좋습니다.

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

SAP 애플리케이션 서버의 고가용성은 애플리케이션 서버 풀 내에서 트래픽 부하를 분산하여 달성됩니다.

데이터베이스 계층

이 아키텍처에서 원본 데이터베이스는 SQL Server, SAP ASE, IBM Db2 또는 Oracle과 같은 DBMS인 AnyDB에서 실행됩니다. 데이터베이스 계층의 네이티브 복제 기능은 복제된 노드 간에 수동 또는 자동 장애 조치(failover)를 제공합니다.

특정 데이터베이스 시스템의 구현에 대한 자세한 내용은 SAP NetWeaver에 대한 Azure Virtual Machines DBMS 배포를 참조하세요.

가용성 영역에 배포된 VM

가용성 영역은 워크로드 가용성을 개선하고 데이터 센터 중단으로부터 애플리케이션 서비스 및 VM을 보호하도록 설계된 논리적 구문입니다. 단일 영역의 VM은 단일 업데이트 또는 장애 도메인에 있는 것처럼 처리됩니다. 영역 배포를 선택하면 동일한 영역의 VM이 장애에 분산되고 최선의 활동으로 도메인을 업그레이드합니다.

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

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

• 한 영역의 VM 간 대기 시간
• 선택한 영역의 VM 간 대기 시간
• 선택한 영역에서 동일한 Azure 서비스(VM 형식)의 가용성

활성/비활성 배포 예제

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

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

활성/활성 배포 예제

활성/활성 배포에서는 애플리케이션 서버 2개 세트가 2개 영역에 걸쳐 빌드됩니다. 각 영역 내에서 각 서버 집합의 두 애플리케이션 서버는 종료되었기 때문에 비활성 상태입니다. 결과적으로 정상 작동 중에는 두 영역 모두에 활성 애플리케이션 서버가 있습니다.

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

영역 1이 오프라인이 되면 중앙 서비스와 데이터베이스 서비스가 영역 2로 장애 조치(failover)됩니다. 휴면 애플리케이션 서버를 온라인으로 전환하여 애플리케이션 처리를 위한 전체 용량을 제공할 수 있습니다.

DR 고려 사항

SAP 애플리케이션 스택의 모든 계층은 다른 DR 전략을 사용합니다.

애플리케이션 서버 계층

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

애플리케이션 서버를 보조 지역에 자동으로 복제하려면 Azure Site Recovery를 사용하는 것이 좋습니다. Site Recovery를 사용하여 다중 계층 SAP NetWeaver 애플리케이션 배포를 위한 DR을 설정할 수도 있습니다.

Central Services

이 SAP 애플리케이션 스택의 구성 요소는 비즈니스 데이터를 유지하지 않습니다. 여러 지역에 걸친 DR 보호를 위해 복제를 사용합니다. 특히 /sapmnt 디렉터리 및 기타 콘텐츠가 포함된 ASCS 클러스터의 SMB Azure 파일 공유 또는 Azure 공유 디스크를 찾습니다. 해당 SMB Azure 파일 공유 또는 DR 지역의 디스크에 해당 데이터를 복제합니다. SIOS를 사용하는 경우 Site Recovery를 사용하여 SIOS DataKeeper 디스크를 사용하여 Central Services 클러스터를 복제할 수 있습니다.

도구를 사용하지 않고 자체 복제 프로세스를 만드는 경우 DR 지역에 VM을 빌드하여 중앙 서비스 역할 및 콘텐츠를 복제할 수 있습니다. 동기화할 기본 중앙 서비스 노드의 유일한 콘텐츠는 /sapmnt 공유입니다. 기본 중앙 서비스 서버에서 구성 변경 또는 커널 업데이트가 발생하는 경우 DR 지역의 VM에서 변경 내용을 반복해야 합니다. 이 복제 방법의 빌드, 복사 및 테스트 장애 조치(failover) 프로세스에 대한 자세한 내용은 SAP NetWeaver: Hyper-V 및 Microsoft Azure 기반 재해 복구 솔루션 빌드의 "4.3. SAP SPOF 계층(ASCS)"를 참조하세요.

데이터베이스 계층

DR에는 데이터베이스의 통합 복제 기술을 사용하는 것이 가장 좋습니다. 예를 들어 SQL Server의 경우 Always On 가용성 그룹을 사용하여 원격 지역의 복제본을 설정하고 수동 장애 조치(failover)를 사용하여 트랜잭션을 비동기적으로 복제하는 것이 좋습니다. 비동기 복제는 주 사이트에서 대화형 워크로드의 성능에 미치는 영향을 방지합니다. 수동 장애 조치(failover)를 사용하는 경우 DR 영향을 평가하고 DR 사이트에서 작동하는 것이 적절한지 결정할 수 있습니다.

데이터베이스 스토리지에 Azure NetApp Files를 사용하는 경우 지역 간 복제를 사용하여 보조 지역에 데이터를 복제할 수 있습니다. 이 기능은 현재 미리 보기로 제공되므로, 프로덕션 워크로드에 대한 요구 사항을 충족하는지 평가해야 합니다.

공유 서비스에 대한 DR

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

Site Recovery를 통한 자동화된 DR

Site Recovery를 사용하여 원래 구성 사이트가 완전히 복제된 사이트를 자동으로 구축하려면 사용자 지정 배포 스크립트를 실행해야 합니다. 예를 들어, Site Recovery는 먼저 가용성 집합에 VM을 배포합니다. 그런 다음 사용자 지정 스크립트를 실행하여 백 엔드 풀이 이미 정의된 기존(미리 빌드된) 부하 분산 장치를 장애 조치(failover) VM의 NIC에 연결합니다. 사용자 지정 Site Recovery 자동화 Runbook 스크립트의 GitHub에 있는 예는 Azure Site Recovery Runbook을 참조하세요.

관리 및 운영 고려 사항

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

Backup

데이터베이스는 낮은 RPO(복구 지점 목표)와 장기 보존이 필요한 중요 워크로드입니다.

• SQL Server 기반 SAP의 한 가지 방식은 Azure Backup을 사용하여 VM에서 실행되는 SQL Server 데이터베이스를 백업하는 것입니다. 또 다른 옵션은 Azure Files 스냅샷을 사용하여 SQL Server 데이터베이스 파일을 백업하는 것입니다.

• Oracle/Windows의 SAP에 대한 내용은 SAP용 Azure VM DBMS 배포의 "백업/복원" 섹션을 참조하세요.

• 다른 데이터베이스인 경우 해당하는 데이터베이스 공급자의 백업 권장 사항을 참조하세요. 데이터베이스가 Windows VSS(볼륨 섀도 복사본 서비스)를 지원하는 경우 애플리케이션 일치 백업을 위해 VSS 스냅샷을 사용합니다.

ID 관리

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

• Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 Azure 리소스에 대한 액세스를 제공합니다.

• LDAP(Lightweight Directory Access Protocol), Azure AD(Azure Active Directory), Kerberos 또는 다른 시스템을 사용하여 Azure VM에 대한 액세스 권한을 부여합니다.

SAP에서 제공하는 서비스를 사용하여 애플리케이션 자체 내에서 액세스를 지원합니다. 또는 OAuth 2.0 및 Azure AD를 사용합니다.

모니터링

Azure Monitor는 원격 분석 데이터를 수집하고 분석하는 정교한 도구를 제공합니다. 이러한 도구를 통해 클라우드 및 온-프레미스 리소스와 애플리케이션의 성능 및 가용성을 최대화할 수 있습니다. Monitor는 이제 Log Analytics 및 Application Insights를 포함합니다. 모니터를 사용하여 인프라 및 애플리케이션 변칙을 모니터링하고, 관리자에게 경고하고, 미리 정의된 조건에 대한 반응을 자동화할 수 있습니다.

SAP 인프라의 리소스 및 서비스 성능을 모니터링할 수 있는 SAP 기반 모니터링 기능을 제공하려면 Azure SAP 고급 모니터링 확장을 사용합니다. 이 확장은 SAP 애플리케이션에 운영 체제 모니터링 및 DBA Cockpit 함수에 대한 Azure 모니터링 통계를 제공합니다. Azure의 SAP에서 실행하려면 SAP 고급 모니터링이 필요합니다. 자세한 내용은 SAP 노트 2191498 "Azure와 Linux의 SAP: 향상된 모니터링"을 참조하세요. SAP 노트에 액세스하려면 SAP 서비스 Marketplace 계정이 필요합니다.

SAP 솔루션을 위한 Azure Monitor는 SAP NetWeaver용 Azure 네이티브 엔드투엔드 모니터링 솔루션이 지향하는 방향입니다. 이 솔루션은 현재 미리 보기로 제공되며 제한된 지역에서만 사용할 수 있습니다. 요구 사항을 충족하는지 신중하게 평가합니다.

SAP 솔루션을 위한 Azure Monitor는 모니터링을 위한 포괄적인 초기 메트릭 및 원격 분석 세트를 제공합니다. 메트릭 정의는 JSON에 SQL 쿼리로 저장됩니다. 요구 사항을 충족하도록 메트릭 정의를 변경할 수 있습니다. 메트릭의 시작 집합은 GitHub를 참조하세요.

보안 고려 사항

SAP는 자체적인 UME(사용자 관리 엔진)를 사용하여 SAP 애플리케이션 및 데이터베이스 내에서 역할 기반 액세스 및 권한 부여를 제어합니다. 자세한 애플리케이션 보안 지침은 SAP NetWeaver 보안 가이드를 참조하세요.

네트워크 보안을 강화하려면 NVA를 사용하여 Web Dispatcher의 서브넷 앞에 방화벽을 만드는 경계 네트워크를 사용하는 것이 좋습니다.

NVA를 배포하여 가상 네트워크 간의 트래픽을 필터링할 수 있지만, SAP 애플리케이션과 데이터베이스 사이에는 배치하지 마세요. 또한 서브넷에 구성된 라우팅 규칙을 확인하고 단일 인스턴스 NVA로 트래픽을 전달하지 않도록 합니다. 전송할 경우 유지 관리 가동 중지 시간과 네트워크 또는 클러스터형 노드 오류가 발생할 수 있습니다.

인프라 보안을 위해 전송 중 데이터와 미사용 데이터가 암호화됩니다. 네트워크 보안에 대한 자세한 내용은 SAP NetWeaver용 Azure Virtual Machines 계획 및 구현의 "보안 권장 사항" 섹션을 참조하세요. 이 문서에서는 애플리케이션 통신을 허용하려면 방화벽에서 열어야 하는 네트워크 포트도 지정합니다.

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

미사용 데이터 암호화의 경우 SQL Server TDE(투명한 데이터 암호화)는 SQL Server, Azure SQL Database 및 Azure Synapse Analytics 데이터 파일을 암호화합니다. 자세한 내용은 SAP NetWeaver용 SQL Server Azure Virtual Machines DBMS 배포를 참조하세요.

방화벽 내부와 외부의 위협을 모니터링하려면 Microsoft Sentinel(미리 보기) 배포를 고려합니다. 이 솔루션은 Azure, 다른 클라우드 또는 온-프레미스에 배포된 SAP 시스템에 대한 위협을 지속적으로 탐지하고 분석합니다. 배포 지침은 Microsoft Sentinel에서 SAP용 Threat Monitoring 배포를 참조하세요.

언제나처럼 보안 업데이트 및 패치를 관리하여 정보 자산을 보호합니다. 이 작업에 엔드투엔드 자동화 접근 방식을 사용하는 것이 좋습니다.

비용 고려 사항

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

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

워크로드에 더 많은 메모리와 더 적은 CPU가 필요한 경우 제한된 vCPU VM 크기 중 하나를 사용하여 vCPU당 청구되는 소프트웨어 라이센스 요금을 줄이는 것이 좋습니다.

VM

이 아키텍처는 애플리케이션 계층과 데이터베이스 계층에 VM을 사용합니다. SAP NetWeaver 계층은 Windows VM을 사용하여 SAP 서비스 및 애플리케이션을 실행합니다. 데이터베이스 계층은 SQL Server, Oracle 또는 IBM DB2와 같은 데이터베이스로 AnyDB를 실행합니다. VM은 관리를 위한 점프 상자로도 사용됩니다.

VM에 대한 몇 가지 지급 조건이 있습니다.

• 워크로드의 완료 시간 또는 리소스 사용량을 예측할 수 없는 경우에는 종량제 옵션을 사용하는 것이 좋습니다.

• 1년 또는 3년 넘게 사용해야 하는 약정을 체결해도 되는 경우에는 Azure Reservations를 사용하는 것이 좋습니다. VM 예약은 비용을 크게 줄일 수 있습니다. 종량제 서비스 비용의 72% 정도만 지불하면 됩니다.

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

• 고성능 컴퓨팅 시나리오, 일괄 처리 작업 또는 시각적 렌더링 애플리케이션
• 연속 통합 및 지속적인 업데이트 워크로드를 포함한 테스트 환경
• 대규모 상태 비저장 애플리케이션

성능 또는 규정 준수를 위해 유지 관리 이벤트 또는 하드웨어 격리에 대해 더 많은 제어가 필요한 경우 전용 호스트에 VM을 배포하는 것이 좋습니다.

VM 및 가용성 집합

모든 풀 및 클러스터(Web Dispatcher, SAP 애플리케이션 서버, 중앙 서비스 및 데이터베이스)에 대해 VM은 별도의 가용성 집합으로 그룹화됩니다. 가용성 집합에 대한 비용은 없습니다. 만드는 각 VM 인스턴스의 요금만 지불하면 됩니다.

가용성 영역에 워크로드를 배포하는 경우 가용성 집합이 필요 없습니다.

Load Balancer

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

구성된 부하 분산 및 아웃바운드 규칙 수와 부하 분산 장치를 통해 처리되는 데이터에 대한 요금만 청구됩니다. 인바운드 NAT(Network Address Translation) 규칙은 무료입니다. 규칙을 구성하지 않으면 표준 Load Balancer에 대한 시간당 요금이 청구되지 않습니다.

ExpressRoute

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

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

커뮤니티

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

• Microsoft 플랫폼에서 SAP 애플리케이션 실행 블로그
• Azure 커뮤니티 지원
• SAP 커뮤니티
• SAP Stack Overflow

참가자

Microsoft에서 이 문서를 유지 관리합니다. 이 문서를 처음에 작성한 기여자는 다음과 같습니다.

보안 주체 작성자:

• Ben Trinh | 수석 설계자

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

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

• SAP NetWeaver에 대한 Azure Virtual Machines 계획 및 구현
• Azure를 사용하여 SAP 워크로드 시나리오 호스트 및 실행

관련 리소스

• Azure에서 Oracle Database를 사용하여 SAP 프로덕션 워크로드 실행
• Azure의 SAP 워크로드에 대한 개발 및 테스트 환경