이 참조 아키텍처는 Azure에서 Oracle Database를 사용하여 고가용성 SAP NetWeaver를 실행하기 위한 검증된 사례 집합을 보여 줍니다. 아키텍처 원칙은 OS에 구애받지 않습니다. 그러나 달리 지정하지 않는 한 아키텍처는 Linux를 기반으로 하는 것으로 간주됩니다.
첫 번째 다이어그램은 Azure의 Oracle에서 SAP에 대한 참조 아키텍처를 보여줍니다. 아키텍처는 가용성 집합을 사용합니다.
이 아키텍처 및 관련 아키텍처의 Visio 파일을 다운로드합니다.
참고 항목
이 참조 아키텍처를 배포하려면 적절한 SAP 제품 및 기타 Microsoft 이외의 기술이 필요합니다.
구성 요소
이 참조 아키텍처는 시스템 가용성을 최대화하기 위해 고가용성 배포에서 Azure에 있는 Oracle Database에서 실행되는 일반적인 SAP 프로덕션 시스템에 대해 설명합니다. 아키텍처 및 해당 구성 요소는 비즈니스 요구 사항(RTO, RPO, 가동 시간 기대치, 시스템 역할)에 따라 사용자 지정될 수 있으며 잠재적으로 단일 VM으로 축소될 수 있습니다. 네트워크 레이아웃은 이러한 SAP 환경의 아키텍처 보안 주제를 시연하기 위해 간소화되었으며 이는 전체 엔터프라이즈 네트워크를 설명하기 위한 것은 아닙니다.
네트워킹
가상 네트워크 Azure Virtual Network 서비스는 보안 강화를 통해 Azure 리소스를 서로 연결합니다. 이 아키텍처에서 가상 네트워크는 허브 스포크 토폴로지의 허브에 배포된 VPN(가상 사설망) 게이트웨이를 통해 온-프레미스 환경에 연결합니다. SAP 애플리케이션 및 데이터베이스는 자체 스포크 가상 네트워크에 포함됩니다. 가상 네트워크는 애플리케이션(SAP NetWeaver), 데이터베이스 및 공유 서비스(예: Azure Bastion)의 각 계층에 대해 별도의 서브넷으로 세분화됩니다.
이 아키텍처는 가상 네트워크 주소 공간을 서브넷으로 세분화합니다. 애플리케이션 서버를 별도의 서브넷에 배치하고 다른 서브넷에 데이터베이스 서버를 배치합니다. 이렇게 하면 개별 서버가 아닌 서브넷 보안 정책을 관리하여 더 쉽게 보호할 수 있으며 데이터베이스에 적용되는 보안 규칙을 애플리케이션 서버와 명확하게 분리할 수 있습니다.
가상 네트워크 피어링. 이 아키텍처는 여러 가상 네트워크가 서로 피어링된 허브-스포크 네트워킹 토폴로지를 사용합니다. 이 토폴로지는 Azure에 배포된 서비스에 대한 네트워크 조각화 및 격리를 제공합니다. 피어링을 사용하면 Microsoft 백본 네트워크를 통해 피어링된 가상 네트워크 간에 투명한 연결이 가능합니다. 단일 지역 내에 배포하면 성능 저하가 발생하지 않습니다.
영역 중복 게이트웨이. 게이트웨이는 고유한 네트워크를 연결하여 온-프레미스 네트워크를 Azure 가상 머신으로 확장합니다. ExpressRoute를 사용하여 공용 인터넷을 통해 이동하지 않는 프라이빗 연결을 만드는 것이 좋지만, 사이트 간 연결을 사용할 수도 있습니다. Azure ExpressRoute 또는 VPN 게이트웨이를 영역 간에 배포하여 영역 오류로부터 보호할 수 있습니다. 영역 중복 배포와 영역 중복 배포 간의 차이점을 이해하려면 영역 중복 가상 네트워크 게이트웨이를 참조하세요. 게이트웨이의 영역 배포에 사용되는 IP 주소는 표준 SKU여야 한다는 점에 주목해야 합니다.
네트워크 보안 그룹. 가상 네트워크에서 들어오고 나가는 서브넷 내 트래픽을 제한하려면 특정 서브넷에 차례로 할당되는 네트워크 보안 그룹을 만듭니다. DB 및 애플리케이션 서브넷은 워크로드별 NSG로 보호됩니다.
애플리케이션 보안 그룹입니다. 애플리케이션을 중심으로 하는 워크로드를 기반으로 NSG 내에서 세분화된 네트워크 보안 정책을 정의하려면 명시적 IP 주소 대신 애플리케이션 보안 그룹을 사용합니다. VM을 이름별로 그룹화하고 네트워크의 신뢰할 수 있는 세그먼트에서 트래픽을 필터링하여 애플리케이션을 보호할 수 있습니다.
NIC(네트워크 인터페이스 카드). 네트워크 인터페이스 카드를 사용하면 가상 네트워크의 모든 가상 머신에서 통신할 수 있습니다. 기존 온-프레미스 SAP 배포는 머신당 여러 NIC를 구현하여 비즈니스 트래픽에서 관리 트래픽을 분리합니다.
Azure에서 가상 네트워크는 동일한 네트워크 구조를 통해 모든 트래픽을 보내는 소프트웨어 정의 네트워크입니다. 따라서 성능상의 이유로 여러 NIC를 사용할 필요는 없습니다. 그러나 조직에서 트래픽을 분리해야 하는 경우 VM당 여러 개의 NIC를 배포하고, 각 NIC를 서로 다른 서브넷에 연결할 수 있습니다. 그런 다음, 네트워크 보안 그룹을 사용하여 각 서브넷에 서로 다른 액세스 제어 정책을 적용할 수 있습니다.
Azure NIC는 여러 IP를 지원합니다. 이 지원은 설치에 가상 호스트 이름을 사용하는 SAP 권장 사례를 준수합니다. 전체 개요는 SAP 노트 962955를 참조하세요. (SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다.)
가상 머신
이 아키텍처는 VM(가상 머신)을 사용합니다. SAP 애플리케이션 계층의 경우 VM은 중앙 서비스 SAP (A)SCS 및 ERS뿐만 아니라 애플리케이션 서버(PAS, AAS)를 비롯한 모든 인스턴스 역할(웹 디스패처 및 애플리케이션 서버)에 대해 배포됩니다. 요구 사항에 따라 가상 머신 수를 조정할 수 있습니다. Azure Virtual Machines 계획 및 구현 가이드에는 가상 머신에서 SAP NetWeaver를 실행하는 방법에 대한 자세한 정보가 나와 있습니다.
Oracle 데이터베이스와 Oracle 관찰자 VM 모두에 사용되는 모든 Oracle 용도의 가상 머신도 마찬가지입니다. 이 아키텍처의 관찰자 VM은 실제 데이터베이스 서버에 비해 작습니다.
- 제한된 vCPU VM. Oracle 라이선스 비용을 잠재적으로 절약하려면 vCPU 제한 VM을 활용하는 것이 좋습니다.
- SAP용 인증된 VM 제품군입니다. Azure 가상 머신 유형 및 처리량 메트릭에 대한 SAP 지원(SAPS)을 자세히 알아보려면 SAP 노트 1928533을 참조하세요. (SAP 노트에 액세스하려면 SAP Service Marketplace 계정이 필요합니다.)
PPG(근접 배치 그룹). 네트워크 대기 시간을 최적화하기 위해 배치를 선호하는 근접 배치 그룹을 사용할 수 있습니다. 즉, 가상 머신이 동일한 데이터 센터에 있으므로 애플리케이션 대기 시간을 최소화할 수 있습니다. 대부분의 SAP 애플리케이션의 사용자 환경을 크게 개선시킬 수 있습니다. PPG의 잠재적 제한으로 인해 SAP 시스템의 PPG에 데이터베이스 AvSet을 추가하는 작업은 SAP 애플리케이션과 데이터베이스 트래픽 간의 대기 시간에 필요한 경우에만 드물게 수행해야 합니다. PPG의 사용 시나리오에 대한 자세한 내용은 연결된 설명서를 참조하세요.
2세대(Gen2) 가상 머신. Azure는 1세대 또는 2세대여야 하는 경우 VM을 배포할 때 선택할 수 있습니다. 2세대 VM은 1세대 VM에서 사용할 수 없는 주요 기능을 지원합니다. 특히 아주 큰 Oracle 데이터베이스의 경우 Mv2 또는 Mdsv2와 같은 일부 VM 제품군은 Gen2 VM으로만 지원되므로 매우 중요합니다. 마찬가지로 일부 최신 VM에 대한 Azure 인증의 SAP는 Azure에서 둘 다 허용하더라도 전체 지원을 위해 Gen2만 필요할 수 있습니다. 자세한 내용은 SAP Note 1928533 - Microsoft의 SAP 애플리케이션: 지원되는 제품 및 Azure VM 유형을 참조하세요.
SAP를 지원하는 다른 모든 VM은 Gen2 전용 또는 Gen1+2를 선택적으로 선택할 수 있으므로 메모리 요구 사항이 아주 낮더라도 모든 SAP VM을 Gen2로 배포하는 것이 좋습니다. Gen2로 배포된 가장 작은 VM도 간단한 할당 취소 및 크기 조정을 통해 사용 가능한 가장 큰 VM으로 확장할 수 있습니다. Gen1 VM은 Gen1 VM을 실행할 수 있는 VM 제품군으로만 크기를 조정할 수 있습니다.
스토리지
이 아키텍처는 가상 머신에 대해 Azure 관리 디스크를, sapmnt 및 SAP 전송 NFS 볼륨과 같은 NFS 공유 스토리지 요구 사항에 대해 Azure Files NFS 또는 Azure NetApp Files 를 사용합니다. Azure에서 SAP를 사용하여 스토리지를 배포하는 데 대한 지침은 SAP 워크로드에 대한 Azure Storage 유형 가이드에 자세히 설명되어 있습니다.
- SAP용 인증된 스토리지입니다. SAP 사용에 대한 인증된 VM 유형과 마찬가지로 SAP 참고 2015553 및 SAP 참고 2039619 세부 정보를 참조하세요.
- Oracle의 SAP에 대한 스토리지 디자인입니다. Sap 워크로드용 Azure Virtual Machines Oracle DBMS 배포의 Azure에서 Oracle의 SAP에 권장되는 스토리지 디자인을 찾을 수 있습니다. 이 문서에서는 파일 시스템 레이아웃, 디스크 크기 조정 권장 사항 및 기타 스토리지 옵션에 대한 특정 지침을 제공합니다.
- Oracle 데이터베이스 파일 저장 Linux ext4 또는 xfs 파일 시스템은 데이터베이스, Windows용 NTFS 배포에 사용해야 합니다. Oracle ASM은 Oracle Database 12c 릴리스 2 이상을 위한 Oracle 배포에도 지원됩니다.
- 관리 디스크에 대한 대안입니다. 또는 Oracle 데이터베이스에 Azure NetApp Files를 사용할 수 있습니다. 자세한 내용은 SAP note 2039619 및 Oracle on Azure 설명서를 참조하세요. Azure Files NFS 볼륨은 Azure NetApp Files와 달리 Oracle 데이터베이스 파일을 저장하기 위한 것이 아닙니다.
- Azure Premium SSD v2 는 SAP와 같은 성능에 중요한 워크로드를 위해 설계되었습니다. 이 스토리지 솔루션의 이점 및 현재 제한 사항은 프리미엄 SSD v2 배포를 참조하세요.
고가용성
위의 아키텍처는 각 애플리케이션 계층이 둘 이상의 가상 머신에 포함된 고가용성 배포를 보여 줍니다. 다음 구성 요소가 사용됩니다.
Azure에서 SAP 워크로드 배포는 SAP 애플리케이션의 가용성 및 복원력 요구 사항에 따라 지역 또는 영역이 될 수 있습니다. Azure는 리소스의 가용성을 높이기 위해 유연한 오케스트레이션(FD=1), 가용성 영역 및 가용성 집합을 사용하는 Virtual Machine Scale Sets와 같은 다양한 배포 옵션을 제공합니다. 여러 Azure 지역(영역 간, 단일 영역 내 또는 영역이 없는 지역 포함)에서 배포 옵션 및 해당 적용 가능성을 포괄적으로 이해하려면 SAP NetWeaver에 대한 고가용성 아키텍처 및 시나리오를 참조하세요.
부하 분산 장치.Azure Load Balancer 는 SAP 서브넷의 가상 머신에 트래픽을 분산하는 데 사용됩니다. SAP 영역 배포에 Azure Load Balancer를 통합하는 경우 표준 SKU 부하 분산 장치를 선택해야 합니다. 기본 SKU 분산 장치는 영역 중복을 지원하지 않습니다.
SAP의 가용성 영역 간에 VM을 배포할 때 결정 요소를 고려합니다. 가용성 영역 배포가 있는 근접 배치 그룹의 사용을 평가하고 애플리케이션 계층 VM에만 사용해야 합니다.
참고
가용성 영역은 지역 내 고가용성을 지원하지만 DR에는 효과적이지 않습니다. 영역 간 거리가 너무 짧습니다. 일반적인 DR 지역은 주 지역에서 100마일 이상 떨어져 있어야 합니다.
Oracle 관련 구성 요소입니다. Oracle Database VM은 가용성 집합 또는 다른 가용성 영역에 배포됩니다. 각 VM에는 데이터베이스 소프트웨어 및 VM 로컬 데이터베이스 스토리지의 자체 설치가 포함됩니다. 데이터베이스 간에 Oracle Data Guard를 통해 동기 데이터베이스 복제본(replica)tion을 설정하여 일관성을 보장하고 개별 오류가 발생한 경우 낮은 RTO 및 RPO 서비스 시간을 허용합니다. Oracle Data Guard Fast-Start Failover 설정에는 데이터베이스 VM 외에도 Oracle Data Guard Observer가 있는 추가 VM이 필요합니다. Oracle Observer VM은 클러스터 관리자 없이 데이터베이스 및 복제 상태를 모니터링하고 자동화된 방식으로 데이터베이스 장애 조치(failover)를 용이하게 합니다. 데이터베이스 복제 관리는 사용 편의성을 위해 Oracle Data Guard Broker를 사용하여 수행할 수 있습니다.
Oracle Data Guard 배포에 대한 자세한 내용은 다음을 참조하세요.
이 아키텍처는 실제 클러스터 설정이나 데이터베이스 계층의 부하 분산 장치 필요 없이 네이티브 Oracle 도구를 활용합니다. Oracle Data Guard Fast-Start Failover 및 SAP 구성을 사용하면 장애 조치(failover) 프로세스가 자동화되고 장애 조치(failover)가 발생할 경우 SAP 애플리케이션이 새 주 데이터베이스에 다시 연결됩니다. SIOS Protection Suite 또는 Veritas InfoScale과 같은 다양한 타사 클러스터 솔루션이 대안으로 존재하며, 각 타사 공급업체의 설명서에서 배포에 대한 세부 정보를 확인할 수 있습니다.
Oracle RAC. RAC(Oracle Real Application Cluster)는 현재 Azure에서 Oracle에서 인증되거나 지원되지 않습니다. 그러나 고가용성을 위한 Oracle Data Guard 기술 및 아키텍처는 랙, 데이터 센터 또는 지역 서비스 중단에 대한 보호를 통해 복원력이 뛰어난 SAP 환경을 제공할 수 있습니다.
NFS 계층입니다. 모든 고가용성 SAP 배포의 경우 복원력 있는 NFS 계층을 사용해야 하며, SAP 전송 디렉터리에 NFS 볼륨, SAP 바이너리에 대한 sapmnt 볼륨 및 (A)SCS 및 ERS 인스턴스에 대한 추가 볼륨을 제공합니다. NFS 계층을 제공하는 옵션은 다음과 같습니다.
- ZRS(영역 중복 스토리지)가 있는 Azure Files NFS - SLES 및 RHEL 가이드
- NFS 볼륨의 Azure NetApp Files 배포 - SLES 및 RHEL 가이드
- VM 기반 NFS 클러스터 - DRBD를 사용하여 VM 간에 복제된 로컬 스토리지가 있는 두 개의 추가 VM(분산 복제된 블록 디바이스) - SLES 및 RHEL 가이드
SAP 중앙 서비스 클러스터. 이 참조 아키텍처는 개별 VM에서 Central Services를 실행합니다. Central Services는 단일 VM에 배포할 때 잠재적인 SPOF(단일 실패 지점)입니다. 고가용성 솔루션을 구현하려면 (A)SCS 및 ERS 인스턴스를 해당 VM으로 장애 조치(failover)하는 클러스터 관리 소프트웨어가 필요합니다. 이는 선택한 NFS 솔루션과 강력하게 연결되므로
선택한 클러스터 솔루션에는 소프트웨어 또는 인프라를 사용할 수 없는 경우 해당 서비스를 제공해야 하는 VM을 결정하는 메커니즘이 필요합니다. Azure의 SAP를 사용하면 STONITH의 Linux 기반 구현에 두 가지 옵션을 사용할 수 있습니다. - 응답하지 않는 VM 또는 애플리케이션을 처리하는 방법
- SUSE-Linux 전용SBD(STONITH 블록 디바이스) - 실제 클러스터 멤버 VM에서 정기적으로 액세스하는 작은 블록 디바이스의 iSCSI 내보내기 역할을 하는 하나 또는 세 개의 추가 VM을 사용하여 이 클러스터 풀에 있는 두 개의 (A)SCS/ERS VM을 사용합니다. VM은 이러한 SBD 탑재를 사용하여 투표를 캐스팅하여 클러스터 결정에 대한 쿼럼을 달성합니다. 이 페이지에 포함된 아키텍처에는 1개 또는 3개의 추가 SBD VM이 포함되어 있지 않습니다. RedHat은 Azure에서 SBD 구현을 지원하지 않으므로 이 옵션은 SUSE SLES 운영 체제에서만 사용할 수 있습니다.
- Azure Fence 에이전트. 추가 VM을 활용하지 않으면 Azure 관리 API는 VM 가용성을 위한 일반 검사 사용됩니다.
NFS 계층 섹션 내에 연결된 가이드에는 각 클러스터 선택에 필요한 단계와 디자인이 포함되어 있습니다. 타사 Azure 인증 클러스터 관리자를 활용하여 SAP 중앙 서비스의 고가용성을 제공할 수도 있습니다.
SAP 애플리케이션 서버 풀. SAP 메시지 서버 또는 웹 디스패처를 통한 부하 분산 요청에 의해 고가용성이 달성되는 둘 이상의 애플리케이션 서버. 각 애플리케이션 서버는 독립적이며 이 VM 풀에 필요한 네트워크 부하 분산이 없습니다.
SAP 웹 디스패처 풀. Web Dispatcher 구성 요소가 SAP 애플리케이션 서버 간의 SAP 트래픽을 위한 부하 분산 장치로 사용됩니다. SAP Web Dispatcher의 고가용성을 달성하기 위해 Azure Load Balancer는 장애 조치(failover) 클러스터 또는 병렬 Web Dispatcher 설정을 구현합니다.
(A)SCS의 Embedded Web Dispatcher는 특별한 옵션입니다. (A)SCS의 추가 워크로드를 감안하여 적절한 크기 조정을 고려해야 합니다.
인터넷 연결 통신의 경우 보안 문제를 해결하기 위해 경계 네트워크(DMZ라고도 함)에서 독립 실행형 솔루션을 사용하는 것이 좋습니다.
Windows 배포. 이 문서는 처음에 소개된 대로 주로 Linux 기반 배포에 초점을 맞췄습니다. Windows를 사용하는 경우 동일한 아키텍처 원칙이 적용되며 Linux와 Windows 간에 Oracle 관련 아키텍처 차이가 없습니다.
SAP 애플리케이션 파트는 아키텍처 가이드 Azure의 Windows에서 SAP NetWeaver 실행의 세부 정보를 참조하세요.
고려 사항
재해 복구
다음 다이어그램은 Azure의 Oracle에서 프로덕션 SAP 시스템의 아키텍처를 보여줍니다. 아키텍처는 DR을 제공하고 가용성 영역을 사용합니다.
이 아키텍처 및 관련 아키텍처의 Visio 파일을 다운로드합니다.
SAP 애플리케이션 스택의 모든 아키텍처 계층은 다른 접근 방식을 사용하여 DR 보호를 제공합니다. DR 전략 및 구현 세부 정보는 SAP 애플리케이션에 대한 SAP 워크로드 및 재해 복구 지침에 대한 재해 복구 개요 및 인프라 지침을 참조하세요.
Backup
Azure의 Oracle 백업은 다음과 같은 여러 방법을 통해 수행할 수 있습니다.
- Azure Backup.Azure는 Oracle 데이터베이스에 대한 스크립트를 제공하고 기본. Oracle 작업이 백업 전 및 사후 실행을 용이하게 합니다.
- Azure Storage. 예를 들어 SAP의 BR 도구로 예약된 파일 기반 데이터베이스 백업을 사용하여 Azure Blob NFS, Azure Blob 또는 Azure Files 스토리지 서비스에서 파일/디렉터리로 저장 및 버전 관리합니다. Oracle 데이터 및 로그 백업을 모두 달성하는 방법에 대한 문서화된 세부 정보를 참조하세요.
- 타사 백업 솔루션. Azure에서 Oracle을 지원하는 백업 스토리지 공급자의 아키텍처를 참조하세요.
비 데이터베이스 VM의 경우 SAP 애플리케이션 VM을 보호하고 SAP Web Dispatcher와 같은 인프라를 둘러싸려면 VM용 Azure Backup이 권장됩니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Robert Biro | 선임 설계자
다음 단계
- Azure VM에서 SAP NetWeaver에 대한 고가용성
- SAP NetWeaver에 대한 Azure Virtual Machines 계획 및 구현
- Azure를 사용하여 SAP 워크로드 시나리오 호스트 및 실행
커뮤니티
커뮤니티는 질문에 대답하고 성공적인 배포를 설정하는 데 도움을 줄 수 있습니다. 다음 리소스를 고려해 보세요.
관련 참고 자료
자세한 내용 및 동일한 기술 중 일부를 사용하는 SAP 워크로드 예제는 다음 문서를 참조하세요.