이 문서에서는 Azure에서 전체 SAP 환경을 설계하기 위한 모범 사례를 제공합니다. SAP 환경에는 허브, 프로덕션, 비프로덕션 및 재해 복구 환경 전반에 걸쳐 여러 SAP 시스템이 포함됩니다. 특정 SAP 시스템이 아닌 네트워크 디자인에 중점을 둔 권장 사항을 제공합니다. 목표는 안전하고 성능이 뛰어나며 탄력적인 SAP 환경을 설계하기 위한 권장 사항을 제공하는 것입니다.
아키텍처
아키텍처의 Visio 파일을 다운로드합니다.
워크플로
- 온-프레미스 네트워크: 온-프레미스 네트워크에서 연결된 Azure 지역으로의 ExpressRoute 연결입니다.
- Azure 구독 지역 허브: SAP뿐만 아니라 기업 전체를 위한 중앙 서비스를 포함하는 Azure 구독입니다. 허브 구독은 SAP 워크로드를 포함하는 스포크 가상 네트워크에 피어링하여 연결을 제공합니다.
- 허브 가상 네트워크: 주 지역 또는 지역 A의 중앙 허브에 대한 가상 네트워크 스포크입니다.
- 허브 DR(재해 복구) 가상 네트워크: 재해 복구 지역의 중앙 허브에 대한 가상 네트워크 스포크입니다. 주 지역에서 프로덕션 가상 네트워크의 서브넷 디자인을 미러링합니다.
- Azure 구독 SAP 비프로덕션: 모든 비프로덕션 SAP 워크로드에 대한 Azure 구독입니다. 여기에는 사전 프로덕션, 품질 보증, 개발 및 샌드박스 환경이 포함됩니다.
- SAP 비프로덕션 스포크 가상 네트워크: 주 지역의 SAP 비프로덕션 워크로드를 위한 별도의 가상 네트워크입니다. 각 SAP 환경에는 고유한 가상 네트워크와 서브넷이 있습니다.
- Azure 구독 SAP 프로덕션: 모든 프로덕션 SAP 워크로드에 대한 Azure 구독입니다.
- SAP 프로덕션 스포크 가상 네트워크: 여러 서브넷이 있는 SAP 프로덕션 환경용 가상 네트워크입니다. 이 가상 네트워크는 주 지역에 있습니다.
- SAP 프로덕션 DR(재해 복구) 스포크 가상 네트워크: 보조 재해 복구 지역의 SAP 프로덕션용 가상 네트워크입니다. 주 지역에서 프로덕션 가상 네트워크의 서브넷 디자인을 미러링합니다.
- Azure 서비스: SAP 환경에 연결할 수 있는 Azure 서비스의 샘플입니다.
- SAP BTP(비즈니스 기술 플랫폼): SAP 환경은 Azure Private Link를 통해 SAP 비즈니스 기술 플랫폼에 액세스합니다.
Azure 구독
허브-스포크 네트워크 디자인을 사용하는 것이 좋습니다. 허브 스포크 디자인을 사용하면 SAP 환경을 나누기 위해 최소 3개의 구독이 필요합니다. (1) 지역 허브 가상 네트워크, (2) 비프로덕션 가상 네트워크 및 (3) 프로덕션 가상 네트워크에 대한 구독이 있어야 합니다. 구독은 청구, 정책 및 보안 경계를 제공합니다. 올바른 구독 수는 없습니다. 사용하는 구독 수는 청구, 정책 및 보안 요구 사항에 따라 다릅니다. 일반적으로 너무 많은 구독을 사용하지 않는 것이 좋습니다. 구독이 너무 많으면 불필요한 관리 오버헤드와 네트워킹 복잡성이 추가될 수 있습니다. 예를 들어, 각 SAP 시스템에 대한 구독이 필요하지 않습니다. Microsoft의 아키텍처는 세 가지 구독을 사용합니다.
지역 허브: 허브 가상 네트워크가 기본 및 보조 지역에 존재하는 Azure 가상 허브 구독입니다. 이 구독은 SAP뿐만 아니라 모든 중앙 서비스를 위한 것입니다.
SAP 비프로덕션: 샌드박스, 개발, 품질 보증 또는 사전 프로덕션 시스템을 포함한 비프로덕션 시스템이 상주하는 Azure SAP 비프로덕션 구독입니다.
SAP 프로덕션: 프로덕션 및 재해 복구 시스템을 구성한 Azure SAP 프로덕션 구독입니다.
자세한 내용은 다음을 참조하세요.
네트워크 설계
허브 스포크 토폴로지는 SAP 환경에 권장되는 네트워크 디자인입니다. 이 토폴로지에서 프로덕션 허브 가상 네트워크는 연결의 중심점 역할을 합니다. 온-프레미스 네트워크와 다양한 스포크 가상 네트워크에 연결하고 사용자와 애플리케이션이 SAP 워크로드에 액세스할 수 있도록 합니다. 이 허브 스포크 토폴로지 내에서 SAP 네트워크 디자인에 대한 권장 사항은 다음과 같습니다.
온-프레미스 연결에 ExpressRoute를 사용합니다. SAP 워크로드의 경우 ExpressRoute를 사용하여 온-프레미스 네트워크를 허브 가상 네트워크 및 허브 DR 가상 네트워크에 연결하는 것이 좋습니다. 전역 위치가 있는 경우 Azure Virtual WAN 토폴로지를 사용할 수 있습니다. S2S(사이트 간) VPN을 Azure ExpressRoute 또는 타사 경로 요구 사항에 대한 백업으로 설정하는 것이 좋습니다.
자세한 내용은 다음을 참조하세요.
환경당 하나의 가상 네트워크를 사용합니다. 환경당 하나의 가상 네트워크(SAP 배포 계층)를 사용하는 것이 좋습니다. 아키텍처는 프로덕션, 개발, 품질 보증 및 샌드박스에 대해 다른 가상 네트워크를 사용합니다. 이 네트워크 디자인은 대기업 아키텍처에 이상적입니다.
중앙 방화벽을 사용합니다. RFC(원격 함수 호출) 연결을 포함하여 스포크 가상 네트워크에 대한 모든 네트워크 트래픽은 허브 가상 네트워크의 중앙 방화벽을 통과해야 합니다. 스포크 가상 네트워크 간의 네트워크 통신(스포크 간 통신)은 허브 가상 네트워크의 Azure Firewall 서브넷에 있는 허브 가상 네트워크 방화벽을 통과합니다. 마찬가지로 스포크 가상 네트워크와 온-프레미스 네트워크 간의 네트워크 통신도 허브 가상 네트워크 방화벽을 통과합니다. 가상 네트워크 피어링을 사용하여 다양한 스포크 가상 네트워크를 허브 가상 네트워크에 연결했습니다. 스포크 가상 네트워크 간의 모든 통신은 허브 가상 네트워크 방화벽을 통과합니다. 방화벽 대신 네트워크 가상 어플라이언스를 사용할 수도 있습니다. 자세한 내용은 네트워크 가상 어플라이언스를 참조하세요.
가상 네트워크에 남아 있는 네트워크 트래픽은 방화벽을 통과하면 안 됩니다. 예를 들어, SAP 애플리케이션 서브넷과 SAP 데이터베이스 서브넷 사이에 방화벽을 두지 마세요. SAP 애플리케이션과 SAP 커널을 실행하는 SAP 시스템의 DBMS(데이터베이스 관리 시스템) 계층 사이에 방화벽 또는 NVA(네트워크 가상 어플라이언스)를 배치할 수 없습니다.
피어링 스포크 가상 네트워크를 방지합니다. 스포크 가상 네트워크 간의 가상 네트워크 피어링은 가능하면 피해야 합니다. 스포크-스포크 가상 네트워크 피어링을 사용하면 스포크 간 통신이 허브 가상 네트워크 방화벽을 우회할 수 있습니다. 대역폭 요구 사항이 높은 경우에만 스포크-스포크 가상 네트워크 피어링을 구성해야 합니다(예: SAP 환경 간의 데이터베이스 복제). 다른 모든 네트워크 트래픽은 허브 가상 네트워크 및 방화벽을 통해 실행되어야 합니다. 자세한 내용은 Azure의 SAP에 대한 인바운드 및 아웃바운드 인터넷 연결을 참조하세요.
서브넷
각 SAP 환경(프로덕션, 사전 프로덕션, 개발, 샌드박스)을 서브넷으로 나누고 서브넷을 사용하여 관련 서비스를 그룹화하는 것이 가장 좋습니다. 다음은 SAP 환경 서브넷에 대한 권장 사항입니다.
서브넷 수
아키텍처의 프로덕션 가상 네트워크에는 5개의 서브넷이 있습니다. 이 디자인은 대기업 솔루션에 이상적입니다. 서브넷의 수는 더 적거나 더 많을 수 있습니다. 가상 네트워크의 리소스 수는 가상 네트워크의 서브넷 수를 결정해야 합니다.
서브넷 크기 조정
서브넷에 충분한 네트워크 주소 공간이 있는지 확인합니다. SAP 가상 호스트 이름을 사용하는 경우 SAP 서브넷에 더 많은 주소 공간이 필요합니다. 종종 각 SAP 인스턴스에는 2-3개의 IP 주소가 필요하며 가상 머신 호스트 이름에 대해 하나의 IP 주소가 포함됩니다. 다른 Azure 서비스는 SAP 워크로드 가상 네트워크에 배포될 때 자체 전용 서브넷이 필요할 수 있습니다.
애플리케이션 서브넷
애플리케이션 서브넷에는 SAP 애플리케이션 서버, ASCS(SAP Central Services), SAP ERS(Enqueue Replication Services) 및 SAP Web Dispatcher 인스턴스를 실행하는 가상 머신이 포함됩니다. 서브넷에는 Azure Files에 대한 프라이빗 엔드포인트도 포함됩니다. 다이어그램에서 가상 머신을 역할별로 그룹화했습니다. 복원력 있는 배포를 위해 유연한 오케스트레이션, 가용성 영역 또는 가용성 집합과 함께 가상 머신 확장 집합을 사용하는 것이 좋습니다. 자세한 내용은 다음 단계를 참조하세요.
데이터베이스 서브넷
데이터베이스 서브넷은 데이터베이스를 실행하는 가상 머신을 보유합니다. 다이어그램에서 동기 복제가 있는 가상 머신 쌍은 하나의 SAP 환경의 모든 데이터베이스 가상 머신을 나타냅니다.
경계 서브넷
경계 서브넷은 인터넷에 연결되어 있으며 SAP 경계 서브넷과 Application Gateway 서브넷을 포함합니다. 다음은 이 두 서브넷을 설계하기 위한 권장 사항입니다.
SAP 경계 서브넷: SAP 경계 서브넷은 SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent 및 Application Gateway와 같은 인터넷 연결 애플리케이션을 포함하는 경계 네트워크입니다. 이러한 서비스에는 SAP 팀이 배포, 관리 및 구성해야 하는 SAP 시스템에 대한 종속성이 있습니다. 중앙 IT 팀은 SAP 경계 서브넷의 서비스를 관리하면 안 됩니다. 이러한 이유로 허브 가상 네트워크가 아닌 SAP 스포크 가상 네트워크에 이러한 서비스를 배치해야 합니다. 아키텍처 다이어그램은 프로덕션 SAP 경계 네트워크만 보여 줍니다. 비프로덕션 가상 네트워크에 SAP 경계 서브넷이 없습니다. 비프로덕션 SAP 구독의 워크로드는 SAP 경계 서브넷의 서비스를 사용합니다.
비프로덕션 구독에서 별도의 SAP 경계 서브넷 집합을 만들 수 있습니다. 자주 변경되는 중요한 워크로드 또는 워크로드에 대해서만 이 방법을 사용하는 것이 좋습니다. 전용 비프로덕션 SAP 경계는 테스트 및 새 기능 배포에 유용합니다. 덜 중요한 애플리케이션이나 시간이 지남에 따라 수정이 거의 없는 애플리케이션에는 별도의 비프로덕션 SAP 경계 서브넷이 필요하지 않습니다.
Application Gateway 서브넷: Azure Application Gateway에는 자체 서브넷이 필요합니다. 이를 사용하여 SAP Fiori와 같은 SAP 서비스가 사용할 수 있는 인터넷 트래픽을 허용합니다. 권장 아키텍처는 허브 가상 네트워크의 프런트 엔드 공용 IP 주소와 함께 Azure Application Gateway 배치합니다. Azure Application Gateway에는 /29 크기 이상의 서브넷이 필요합니다. 크기가 /27 이상인 것이 좋습니다. 동일한 서브넷에서 두 버전의 Application Gateway(v1 및 v2)를 모두 사용할 수 없습니다. 자세한 내용은 Azure Application Gateway의 서브넷을 참조하세요.
보안 강화를 위해 별도의 가상 네트워크에 경계 서브넷 배치: 보안 강화를 위해 SAP 프로덕션 구독 내의 별도 가상 네트워크에 SAP 경계 서브넷과 Application Gateway 서브넷을 배치할 수 있습니다. SAP 경계 스포크 가상 네트워크는 허브 가상 네트워크와 피어링되며 공용 네트워크에 대한 모든 네트워크 트래픽은 경계 가상 네트워크를 통해 흐릅니다. 이 대체 방법은 SAP 전용 스포크 가상 네트워크에 배치된 인바운드 연결에 대한 공용 IP 주소가 있는 Azure Application Gateway 보여 줍니다.
이 대체 아키텍처를 포함하여 Visio 파일을 다운로드합니다.
이 네트워크 디자인은 더 나은 인시던트 응답 기능과 세분화된 네트워크 액세스 제어를 제공합니다. 그러나 관리 복잡성, 네트워크 대기 시간 및 배포 비용도 증가합니다. 각 사항에 대해 설명해 보겠습니다.
인시던트 응답 개선: SAP 경계 스포크 가상 네트워크를 통해 침해를 검색한 경우 손상된 서비스를 신속하게 격리할 수 있습니다. SAP 경계 스포크 가상 네트워크에서 허브로의 가상 네트워크 피어링을 제거하고 인터넷에서 SAP 경계 워크로드 및 SAP 애플리케이션 가상 네트워크 애플리케이션을 즉시 격리할 수 있습니다. 인시던트 응답을 위해 NSG(네트워크 보안 그룹) 규칙 변경에 의존하지 않으려고 합니다. NSG 규칙을 변경하거나 제거하면 새 연결에만 영향을 미치며 기존의 악의적인 연결은 차단되지 않습니다.
세밀한 네트워크 액세스 제어: SAP 경계 가상 네트워크는 SAP 프로덕션 스포크 가상 네트워크에 대한 보다 엄격한 네트워크 액세스 제어를 제공합니다.
복잡성, 대기 시간 및 비용 증가: 아키텍처는 관리 복잡성, 비용 및 대기 시간을 증가시킵니다. SAP 프로덕션 가상 네트워크의 인터넷 바인딩 통신은 두 번 피어링됩니다. 한 번은 허브 가상 네트워크로 피어링되고 다시 SAP 경계 가상 네트워크로 인터넷으로 연결됩니다. 허브 가상 네트워크의 방화벽은 대기 시간에 가장 큰 영향을 미칩니다. 사용 사례에서 지원할 수 있는지 확인하기 위해 대기 시간을 측정하는 것이 좋습니다.
자세한 내용은 경계 네트워크 모범 사례를 참조하세요.
Azure NetApp Files 서브넷
NetApp Files를 사용하는 경우 Azure의 다양한 SAP 시나리오에 NFS(네트워크 파일 시스템) 또는 SMB(서버 메시지 블록) 파일 공유를 제공하기 위해 위임된 서브넷이 있어야 합니다. /24 서브넷은 NetApp Files 서브넷의 기본 크기이지만 필요에 맞게 크기를 변경할 수 있습니다. 고유의 요구 사항을 사용하여 적절한 크기를 결정합니다. 자세한 내용은 위임된 서브넷을 참조하세요.
서브넷 보안
서브넷을 사용하여 보안 규칙 요구 사항이 동일한 SAP 리소스를 그룹화하면 보안을 보다 쉽게 관리할 수 있습니다.
NSG(네트워크 보안 그룹): 서브넷을 사용하면 서브넷 수준에서 네트워크 보안 그룹을 구현할 수 있습니다. 서로 다른 보안 규칙이 필요한 동일한 서브넷의 리소스를 그룹화하려면 서브넷 수준 및 네트워크 인터페이스 수준에서 네트워크 보안 그룹이 필요합니다. 이 2단계 설정을 사용하면 보안 규칙이 쉽게 충돌하고 해결하기 어려운 예기치 않은 통신 문제가 발생할 수 있습니다. NSG 규칙은 서브넷 내의 트래픽에도 영향을 미칩니다. NSG에 대한 자세한 내용은 네트워크 보안 그룹을 참조하세요.
ASG(애플리케이션 보안 그룹): 애플리케이션 보안 그룹을 사용하여 가상 머신 네트워크 인터페이스를 그룹화하고 네트워크 보안 그룹 규칙에서 애플리케이션 보안 그룹을 참조하는 것이 좋습니다. 이 구성을 사용하면 SAP 배포에 대한 규칙 만들기 및 관리가 더 쉬워집니다. 각 네트워크 인터페이스는 네트워크 보안 그룹 규칙이 다른 여러 애플리케이션 보안 그룹에 속할 수 있습니다. 자세한 내용은 애플리케이션 보안 그룹을 참조하세요.
Azure Private Link
네트워크 통신의 보안을 개선하려면 Azure Private Link를 사용하는 것이 좋습니다. Azure Private Link는 개인 IP 주소가 있는 프라이빗 엔드포인트를 사용하여 Azure 서비스와 통신합니다. Azure Private Links는 인터넷을 통해 공용 엔드포인트로 네트워크 통신을 보내는 것을 방지합니다. 자세한 내용은 Azure 서비스의 프라이빗 엔드포인트를 참조하세요.
애플리케이션 서브넷에서 프라이빗 엔드포인트 사용: 프라이빗 엔드포인트를 사용하여 애플리케이션 서브넷을 지원되는 Azure 서비스에 연결하는 것이 좋습니다. 아키텍처에는 각 가상 네트워크의 애플리케이션 서브넷에 Azure Files에 대한 프라이빗 엔드포인트가 있습니다. 이 개념을 지원되는 모든 Azure 서비스로 확장할 수 있습니다.
SAP BTP(Business Technology Platform)용 Azure Private Link 사용: 이제 SAP BTP(Business Technology Platform)용 Azure Private Link가 일반 공급됩니다. SAP Private Link 서비스는 SAP BTP, Cloud Foundry 런타임 및 기타 서비스의 연결을 지원합니다. 예 시나리오에는 가상 머신에서 실행되는 SAP S/4HANA 또는 SAP ERP가 포함됩니다. Azure Database for MariaDB 및 Azure Database for MySQL과 같은 Azure 네이티브 서비스에 연결할 수 있습니다.
아키텍처는 SAP BTP 환경에서 SAP Private Link 서비스 연결을 설명합니다. SAP Private Link 서비스는 특정 SAP BTP 서비스와 각 네트워크의 특정 서비스 간에 서비스 공급자 계정으로 프라이빗 연결을 설정합니다. 프라이빗 링크를 사용하면 BTP 서비스가 개인 네트워크 연결을 통해 SAP 환경에 액세스할 수 있습니다. 공용 인터넷을 사용하여 통신하지 않음으로써 보안을 개선시킵니다.
자세한 내용은 다음을 참조하세요.
NFS(네트워크 파일 시스템) 및 SMB(서버 메시지 블록) 파일 공유
SAP 시스템은 종종 네트워크 파일 시스템 볼륨 또는 서버 메시지 블록 공유에 의존합니다. 이러한 파일 공유는 가상 머신 간에 파일을 이동하거나 다른 애플리케이션과의 파일 인터페이스로 작동합니다. NFS(네트워크 파일 시스템) 및 SMB(서버 메시지 블록) 파일 공유로 Azure Premium Files 및 Azure NetApp Files와 같은 네이티브 Azure 서비스를 사용하는 것이 좋습니다. Azure 서비스는 운영 체제 기반 도구보다 결합된 가용성, 복원력 및 SLA(서비스 수준 계약)가 더 좋습니다.
자세한 내용은 다음을 참조하세요.
SAP 솔루션을 설계할 때 개별 파일 공유 볼륨의 크기를 적절하게 조정하고 연결되는 SAP 시스템 파일 공유를 알아야 합니다. 계획하는 동안 Azure 서비스의 확장성 및 성능 대상을 염두에 두세요. 다음 표에서는 일반적인 SAP 파일 공유를 간략하게 설명하고 간략한 설명과 전체 SAP 환경에서의 권장 사용을 제공합니다.
| 파일 공유 이름 | 사용량 | 권장 |
|---|---|---|
sapmnt |
분산 SAP 시스템, 프로필 및 전역 디렉터리 | 각 SAP 시스템에 대한 전용 공유, 재사용 없음 |
cluster |
ASCS, ERS 및 각 디자인별 데이터베이스에 대한 고가용성 공유 | 각 SAP 시스템에 대한 전용 공유, 재사용 없음 |
saptrans |
SAP 전송 디렉터리 | 하나 또는 소수의 SAP 환경(ERP, 비즈니스 웨어하우스)에 대한 하나의 공유 |
interface |
비 SAP 애플리케이션과의 파일 교환 | 고객별 요구 사항, 환경당 별도의 파일 공유(프로덕션, 비프로덕션) |
서로 다른 SAP 환경 간에는 saptrans만 공유할 수 있으므로 배치를 신중하게 고려해야 합니다. 확장성과 성능상의 이유로 너무 많은 SAP 시스템을 하나의 saptrans 공유로 통합하지 마세요.
기업 보안 정책은 아키텍처와 환경 간의 볼륨 분리를 주도합니다. 환경 또는 계층별로 분리된 전송 디렉터리는 SAP 전송 그룹 또는 전송 도메인 링크를 허용하기 위해 SAP 환경 간의 RFC 통신이 필요합니다. 자세한 내용은 다음을 참조하세요.
Data services
아키텍처에는 SAP 데이터 플랫폼을 확장하고 개선할 수 있도록 하는 Azure 데이터 서비스가 포함되어 있습니다. 비즈니스 인사이트를 확보하려면 Azure Synapse Analytics, Azure Data Factory 및 Azure Data Lake Storage와 같은 서비스를 사용하는 것이 좋습니다. 이러한 데이터 서비스는 SAP 데이터 및 비SAP 데이터를 분석하고 시각화하는 데 도움이 됩니다.
많은 데이터 통합 시나리오의 경우 통합 런타임이 필요합니다. Azure 통합 런타임은 Azure Data Factory와 Azure Synapse Analytics 파이프라인이 데이터 통합 기능을 제공하는 데 사용하는 컴퓨팅 인프라입니다. 이러한 서비스를 위한 런타임 가상 머신은 각 환경별로 개별적으로 배포하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.
- Azure 통합 런타임
- SAP CDC 솔루션에서 사용할 자체 호스팅 통합 런타임 설정
- SAP HANA에서 데이터 복사
- Open Hub를 통해 SAP Business Warehouse에서 데이터 복사
공유 서비스
SAP 솔루션은 공유 서비스에 의존합니다. 부하 분산 장치 및 애플리케이션 게이트웨이는 여러 SAP 시스템에서 사용하는 서비스의 예입니다. 아키텍처가 아니라 조직의 요구 사항에 따라 공유 서비스를 설계하는 방법이 결정되어야 합니다. 따라야 할 일반적인 지침은 다음과 같습니다.
부하 분산 장치: SAP 시스템당 하나의 부하 분산 장치를 권장합니다. 이 구성은 복잡성을 최소화하는 데 도움이 됩니다. 단일 부하 분산 장치에서 너무 많은 풀과 규칙을 피하려고 합니다. 이 구성은 또한 명명 및 배치가 SAP 시스템 및 리소스 그룹과 일치하도록 합니다. 클러스터된 HA(고가용성) 아키텍처가 있는 각 SAP 시스템에는 하나 이상의 부하 분산 장치가 있어야 합니다. 아키텍처는 ASCS 가상 머신용으로 하나의 부하 분산 장치를 사용하고 데이터베이스 가상 머신용으로 두 번째 부하 분산 장치를 사용합니다. 일부 데이터베이스는 고가용성 배포를 만들기 위해 부하 분산 장치가 필요하지 않을 수 있습니다. SAP HANA는 그렇습니다. 자세한 내용은 데이터베이스 관련 설명서를 확인합니다.
애플리케이션 게이트웨이: 연결된 시스템의 복잡성과 수가 너무 높지 않은 한 SAP 환경(프로덕션, 비프로덕션 및 샌드박스)당 하나 이상의 애플리케이션 게이트웨이를 권장합니다. 환경의 모든 SAP 시스템에 공용 액세스가 필요한 것은 아니므로 여러 SAP 시스템에 애플리케이션 게이트웨이를 사용하여 복잡성을 줄일 수 있습니다. 단일 애플리케이션 게이트웨이는 단일 SAP S/4HANA 시스템에 대해 여러 Web Dispatcher 포트를 제공하거나 다른 SAP 시스템에서 사용할 수 있습니다.
SAP Web Dispatcher 가상 머신: 아키텍처는 2개 이상의 SAP Web Dispatcher VM 풀을 보여 줍니다. 서로 다른 SAP 컴퓨터 간에 SAP Web Dispatcher 가상 머신을 재사용하지 않는 것이 좋습니다. 이를 별도로 유지하면 Web Dispatcher 가상 머신의 크기를 조정하여 각 SAP 컴퓨터의 요구 사항을 충족할 수 있습니다. 소규모 SAP 솔루션의 경우 ASCS 인스턴스에 Web Dispatcher 서비스를 포함하는 것이 좋습니다.
SAP 서비스: SAProuter, Cloud Connector 및 Analytics Cloud Agent와 같은 SAP 서비스는 애플리케이션 요구 사항에 따라 중앙에서 또는 분할로 배포됩니다. 다양한 고객 요구 사항으로 인해 SAP 시스템 간 재사용에 대한 권장 사항이 없습니다. 비프로덕션용 SAP 경계 서브넷을 사용해야 하는 경우 네트워킹 섹션에 주요 결정 사항이 언급되어 있습니다. 그렇지 않으면 SAP용 프로덕션 경계 서브넷만 있는 경우 SAP 경계 서비스는 전체 SAP 환경에서 사용됩니다.
재해 복구
DR(재해 복구)은 기본 Azure 지역을 사용할 수 없거나 손상된 경우 비즈니스 연속성에 대한 요구 사항을 해결합니다. 전체 SAP 환경 관점에서 다이어그램에 표시된 재해 복구 디자인에 대한 권장 사항은 다음과 같습니다.
다른 IP 주소 범위 사용 가상 네트워크는 단일 Azure 지역에만 적용됩니다. 모든 재해 복구 솔루션은 다른 지역을 사용해야 합니다. 보조 지역에 다른 가상 네트워크를 만들어야 합니다. DR 환경의 가상 네트워크는 데이터베이스 고유 기술을 통해 데이터베이스 동기화를 가능하게 하기 위해 다른 IP 주소 범위가 필요합니다.
중앙 서비스 및 온-프레미스 연결: 재해 복구 지역에서 온-프레미스 및 주요 중앙 서비스(DNS 또는 방화벽)에 대한 연결을 사용할 수 있어야 합니다. 중앙 IT 서비스의 가용성 및 구성 변경은 재해 복구 계획의 일부가 되어야 합니다. 중앙 IT 서비스는 제대로 작동하는 SAP 환경의 핵심 구성 요소입니다.
Azure Site Recovery 사용 Azure Site Recovery는 애플리케이션 서버에 대한 관리 디스크 및 가상 머신 구성을 DR 지역에 복제하고 보호합니다.
파일 공유 가용성 보장: SAP는 주요 파일 공유의 가용성에 의존합니다. DR 시나리오에서 데이터 손실을 최소화하면서 이러한 파일 공유에 데이터를 제공하려면 백업 또는 지속적인 파일 공유 복제가 필요합니다.
데이터베이스 복제 Azure Site Recovery는 높은 변경률과 서비스의 데이터베이스 지원 부족으로 인해 SAP 데이터베이스 서버를 보호할 수 없습니다. 재해 복구 지역에 대한 연속 및 비동기 데이터베이스 복제를 구성해야 합니다.
자세한 내용은 SAP 워크로드에 대한 재해 복구 개요 및 인프라 가이드라인을 참조하세요.
더 작은 SAP 아키텍처
더 작은 SAP 솔루션의 경우 네트워크 디자인을 간소화하는 것이 도움이 될 수 있습니다. 각 SAP 환경의 가상 네트워크는 이렇게 결합된 가상 네트워크 내부의 서브넷이 됩니다. 네트워크 및 구독 디자인 요구 사항의 단순화는 보안에 영향을 미칠 수 있습니다. 네트워크 라우팅, 공용 네트워크에 대한 액세스, 공유 서비스(파일 공유)에 대한 액세스 및 기타 Azure 서비스에 대한 액세스를 재평가해야 합니다. 다음은 조직의 요구 사항을 더 잘 충족하기 위해 아키텍처를 축소하기 위한 몇 가지 옵션입니다.
SAP 애플리케이션과 데이터베이스 서브넷을 하나로 결합합니다. 애플리케이션과 데이터베이스 서브넷을 결합하여 하나의 대규모 SAP 네트워크를 만들 수 있습니다. 이 네트워크 디자인은 많은 온-프레미스 SAP 네트워크를 미러링합니다. 이 두 서브넷을 조합하려면 서브넷 보안 및 네트워크 보안 그룹 규칙에 더 많은 주의를 기울여야 합니다. 애플리케이션 보안 그룹은 SAP 애플리케이션 및 데이터베이스 서브넷에 대해 단일 서브넷을 사용할 때 중요합니다.
SAP 경계 서브넷과 애플리케이션 서브넷을 결합합니다. 경계 서브넷과 SAP 애플리케이션 서브넷을 결합할 수 있습니다. 네트워크 보안 그룹 규칙 및 애플리케이션 보안 그룹 사용에 더 많은 주의를 기울여야 합니다. 소규모 SAP 자산에 대해서만 이 단순화 방식을 권장합니다.
다른 SAP 환경 간에 SAP 스포크 가상 네트워크 결합 이 아키텍처는 각 SAP 환경(허브, 프로덕션, 비프로덕션 및 재해 복구)에 대해 서로 다른 가상 네트워크를 사용합니다. SAP 환경의 크기에 따라 SAP 스포크 가상 네트워크를 더 적거나 단 하나의 SAP 스포크로 결합할 수 있습니다. 여전히 프로덕션 환경과 비프로덕션 환경을 구분해야 합니다. 각 SAP 프로덕션 환경은 하나의 SAP 프로덕션 가상 네트워크에서 서브넷이 됩니다. 각 SAP 비프로덕션 환경은 하나의 SAP 비프로덕션 가상 네트워크에서 서브넷이 됩니다.
참가자
Microsoft는 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Robert Biro | 선임 설계자
- Pankaj Meshram | 수석 프로그램 관리자