SAP 마이그레이션을 위한 네트워크 토폴로지 및 연결

이 문서는 네트워크 토폴로지 및 연결에 대한 Azure 랜딩 존 디자인 영역에 정의된 고려 사항 및 권장 사항을 기반으로 합니다. 이 문서의 지침에서는 Microsoft Azure 및 SAP 배포 내에서 네트워킹 및 연결에 대한 주요 디자인 고려 사항 및 모범 사례를 살펴봅니다. SAP는 중요 업무용 플랫폼이므로 디자인은 Azure 랜딩 존 디자인 영역에 대한 지침도 따라야 합니다.

IP 주소 지정 계획

Azure의 IP 주소 지정 계획은 다음을 보장하는 데 중요합니다.

• IP 주소 공간은 온-프레미스 위치 및 Azure 지역과 겹치지 않습니다.
• 가상 네트워크에 올바른 주소 공간이 포함되어 있습니다.
• 서브넷 구성 계획은 미리 수행됩니다.

다음 아키텍처 다이어그램은 Azure 랜딩 존 가속기에서 SAP의 네트워킹 고려 사항을 보여 줍니다.

SAP 구현을 위한 디자인 고려 사항:

특정 서비스에 서브넷을 바치고 위임한 다음 해당 서브넷 내에서 해당 서비스의 인스턴스를 만들 수 있습니다. Azure는 가상 네트워크에서 여러 위임된 서브넷을 만드는 데 도움이 되지만 Azure NetApp Files에 대한 가상 네트워크에 위임된 서브넷을 하나만 가질 수 있습니다. Azure NetApp Files에 둘 이상의 위임된 서브넷을 사용하는 경우 새 볼륨을 만들 수 없습니다.

사용 사례:

Azure NetApp Files를 구현하려면 위임된 서브넷이 필요합니다. 이 방법은 파일 시스템을 공유하는 SAP 배포에 널리 사용됩니다. 부하 분산 중에 애플리케이션 게이트웨이 또는 부하 분산 SAP 웹 애플리케이션 서버인 SAP BusinessObjects Business Intelligence에 대해서만 위임된 서브넷이 필요합니다.

온-프레미스 및 Azure 리소스에 대한 DNS 및 이름 확인 구성

DO기본 DNS(이름 시스템)는 Azure 랜딩 존 아키텍처의 중요한 부분입니다. 기존에 투자한 DNS 자산을 사용하려는 조직도 있을 것이고, 클라우드 채택을 내부 DNS 인프라를 현대화하고 네이티브 Azure 기능을 사용할 수 있는 기회로 간주하는 조직도 있을 것입니다.

SAP 구현을 위한 디자인 권장 사항:

마이그레이션 중에 가상 머신의 DNS 또는 가상 이름이 변경되지 않는 경우 다음 사용 사례 권장 사항을 사용합니다.

사용 사례:

• 백그라운드 DNS 및 가상 이름은 SAP 환경에서 많은 시스템 인터페이스를 연결하며, 고객은 시간이 지나면서 개발자가 정의하는 인터페이스만 알고 있는 경우가 가끔 있습니다. 커넥트이온 문제는 마이그레이션 후 가상 또는 DNS 이름이 변경될 때 시스템 간에 발생합니다. 간단히 하기 위해 DNS 별칭을 유지하는 것이 좋습니다.

• 다른 DNS 영역을 사용하여 샌드박스, 개발, 사전 프로덕션 및 프로덕션 환경을 비롯한 각 환경을 서로 구분합니다. 한 가지 예외는 자체 가상 네트워크가 있는 SAP 배포에 대한 것입니다. 이 시나리오에서는 프라이빗 DNS 영역이 필요하지 않을 수 있습니다.

Azure 네트워크 토폴로지 정의

엔터프라이즈 규모 랜딩 존은 두 개의 네트워크 토폴로지 기능을 지원합니다. 한 토폴로지는 Azure Virtual WAN을 기반으로 합니다. 다른 하나는 허브 및 스포크 아키텍처를 기반으로 하는 기존 네트워크 토폴로지입니다. 이 섹션에서는 두 배포 모델에 권장되는 SAP 구성 및 사례를 설명합니다.

조직에서 다음을 계획하는 경우 Virtual WAN 기반의 네트워크 토폴로지를 사용합니다.

• 여러 Azure 지역에 리소스를 배포하고 글로벌 위치를 Azure 및 온-프레미스 환경 모두에 연결합니다.
• 소프트웨어 정의 WAN 배포를 Azure와 완전히 통합합니다.
• 하나의 Virtual WAN 허브에 연결된 모든 가상 네트워크에 최대 2,000개의 가상 머신 워크로드를 배포합니다.

조직에서 Virtual WAN을 사용하여 대규모 상호 연결 요구 사항을 충족합니다. Microsoft는 전체 네트워크 복잡성을 줄이고 조직의 네트워크를 현대화하는 데 도움이 되는 이 서비스를 관리합니다.

조직인 경우 허브 및 스포크 아키텍처를 기반으로 기존 Azure 네트워크 토폴로지를 사용합니다.

• 선택한 Azure 지역에만 리소스를 배포할 계획입니다.
• 상호 연결된 글로벌 네트워크가 필요 없습니다.
• 지역당 원격 또는 분기 위치가 거의 없으며 IPSec(인터넷 프로토콜 보안) 터널이 30개 미만이어야 합니다.
• Azure 네트워크를 수동으로 구성할 수 있도록 모든 권한 및 세분성이 필요합니다.

SAP 구현을 위한 디자인 권장 사항:

• Azure 지역 및 온-프레미스 위치에서 글로벌 전송 연결이 필요한 신규, 대규모 또는 글로벌 네트워크에서 Azure 배포에 Virtual WAN을 사용합니다. 이 방법을 사용하면 Azure 네트워킹에 대한 전이적 라우팅을 수동으로 설정할 필요가 없으며 Azure 배포에서 SAP에 대한 표준을 따를 수 있습니다.

• 파트너 NVA를 사용하는 경우에만 지역 간에 NVA(네트워크 가상 어플라이언스)를 배포하는 것이 좋습니다. 네이티브 NVA가 있는 경우 지역 또는 가상 네트워크 간의 NVA가 필요하지 않습니다. 파트너 네트워킹 기술 및 NVA를 배포하는 경우 공급업체의 지침에 따라 Azure 네트워킹과 충돌하는 구성을 식별합니다.

• Virtual WAN은 Virtual WAN 기반 토폴로지의 스포크 가상 네트워크 간 연결을 관리하므로 UDR(사용자 정의 경로) 또는 NVA를 설정할 필요가 없습니다. 동일한 가상 허브의 네트워크 간 트래픽에 대한 최대 네트워크 처리량은 50Gbps입니다. 이 대역폭 제한을 극복하기 위해 SAP 랜딩 존은 가상 네트워크 피어링을 사용하여 다른 랜딩 존에 연결할 수 있습니다.

• 두 토폴로지 모두 SAP 애플리케이션과 데이터베이스 서버 간의 NVA 배포를 지원하지 않습니다.

• 로컬 및 글로벌 가상 네트워크 피어링은 연결을 제공하며 여러 Azure 지역에서 SAP 배포를 위한 랜딩 존 간의 연결을 보장하는 기본 접근 방식입니다.

인바운드 및 아웃바운드 인터넷 연결 계획

이 섹션에서는 공용 인터넷으로의 인바운드 및 아웃바운드 연결에 권장되는 연결 모델에 대해 설명합니다. Azure Firewall, Azure 애플리케이션 Gateway의 Azure Web Application Firewall 및 Azure Front Door와 같은 Azure 네이티브 네트워크 보안 서비스는 완전히 관리되는 서비스이므로 인프라 배포와 관련된 운영 및 관리 비용이 발생하지 않습니다.

SAP 구현을 위한 디자인 권장 사항:

• 글로벌 공간을 가진 고객을 위해 Azure Front Door 는 웹 애플리케이션 방화벽 정책을 사용하여 Azure 지역 전체에서 글로벌 HTTP 및 HTTPS 애플리케이션을 제공하고 보호함으로써 SAP 배포를 용이하게 합니다.

• Azure Front Door 및 Application Gateway를 사용하여 HTTP 및 HTTPS 애플리케이션을 보호할 때 Azure Front Door에서 웹 애플리케이션 방화벽 정책을 활용합니다. Azure Front Door에서만 트래픽을 수신하도록 Application Gateway에 대한 트래픽을 차단합니다.

• Application Gateway가 SAP 웹앱의 역방향 프록시 역할을 하는 경우 Application Gateway 및 웹 애플리케이션 방화벽에는 제한이 있습니다. SAP Web Dispatcher 및 NetScaler는 Application Gateway보다 지능적이므로 Application Gateway로 교체하는 경우 광범위한 테스트를 수행해야 합니다. 최신 상태 확인하고 가능한 경우 지원되지 않고 테스트되고 테스트되지 않은 시나리오를 모두 나열합니다.

• 웹 애플리케이션 방화벽을 사용하여 인터넷에 노출될 때 트래픽을 검색합니다. 또 다른 옵션은 부하 분산 장치 또는 기본 제공 방화벽 기능이 있는 Application Gateway 또는 타사 솔루션과 같은 리소스와 함께 사용하는 것입니다.

• 데이터 유출을 방지하려면 Azure Private Link를 사용하여 Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2 및 Azure Data Factory와 같은 PaaS(Platform as a Service) 리소스에 안전하게 액세스합니다. 프라이빗 엔드포인트는 가상 네트워크와 Azure Storage 및 Azure Backup과 같은 서비스 간의 트래픽을 보호하는 데 도움이 될 수도 있습니다. 가상 네트워크와 프라이빗 엔드포인트 사용 서비스 간의 트래픽은 Microsoft 글로벌 네트워크를 통해 이동하므로 공용 인터넷에 노출되지 않습니다.

고가용성을 사용하여 Azure ExpressRoute 구현

Azure ExpressRoute는 Microsoft 리소스에 대한 통신 사업자급 프라이빗 네트워크 연결을 제공하기 위해 고가용성을 위해 설계되었습니다. Microsoft 네트워크 내의 ExpressRoute 경로에는 단일 실패 지점이 없습니다. 가용성을 최대화하려면 고가용성을 위해 ExpressRoute 회로의 고객 및 서비스 공급자 세그먼트도 빌드해야 합니다.

SAP 구현에 대한 디자인 권장 사항:

• ExpressRoute 회로의 두 물리적 링크를 네트워크의 두 개의 고유 에지 디바이스에 연결해야 합니다. ExpressRoute 회로의 가용성을 최대화하기 위한 권장 사항은 ExpressRoute 회로 복원력 권장 사항을 참조 하세요.
• ExpressRoute의 고가용성을 보장합니다. 자세한 내용은 ExpressRoute를 사용하여 고가용성을 위한 설계를 참조 하세요.
• ExpressRoute에 대한 잘 구성된 검토를 수행합니다. 자세한 내용은 Azure Well-Architected Framework 검토 - Azure ExpressRoute 권장 사항을 참조 하세요.
• ExpressRoute에 대한 재해 복구 계획이 있는지 확인합니다. 자세한 내용은 ExpressRoute 개인 피어링을 사용하여 재해 복구를 위한 설계를 참조 하세요.
• ExpressRoute 회로의 두 연결이 모두 활성-활성 모드로 구성되어 있는지 확인합니다. 자세한 내용은 ExpressRoute - 활성-활성 연결을 사용하여 고가용성을 위한 설계를 참조 하세요.
• ExpressRoute 회로에 대한 모니터링 및 경고를 구성합니다.
• ExpressRoute 회로 기본 테넌트 알림을 받도록 서비스 상태를 구성합니다.

네트워크 암호화 요구 사항 정의

이 섹션에서는 온-프레미스 환경과 Azure 환경 간 및 Azure 지역 간에 네트워크를 암호화하기 위한 주요 권장 사항을 살펴봅니다.

SAP 구현에 대한 디자인 고려 사항:

• ExpressRoute를 사용하여 프라이빗 피어링을 구성하는 경우 트래픽은 기본적으로 암호화되지 않습니다.

• SAP 배포를 위해 ExpressRoute를 통해 트래픽을 암호화할 필요가 없습니다. SAP 트래픽은 일반적으로 대역폭을 많이 사용하며 성능에 민감합니다. IPSec 터널은 기본적으로 인터넷 트래픽을 암호화하며 암호화 또는 암호 해독은 트래픽 성능에 부정적인 영향을 줄 수 있습니다.

• 고객은 SAP 트래픽을 암호화해야 하는지 여부를 결정합니다. 엔터프라이즈 규모 랜딩 존의 네트워크 암호화 옵션에 대한 자세한 내용은 네트워크 토폴로지 및 연결을 참조 하세요.

시스템 분리

SAP 시나리오에서는 개발, 테스트, 품질, 사전 제작 및 프로덕션 환경을 비롯한 다양한 환경이 있으며, 고객은 이러한 시스템을 논리적 또는 물리적 구문으로 분류하여 보안 및 규정 준수 표준을 유지하는 경향이 있습니다. 하나의 공통 리소스 그룹에서 수명 주기가 동일한 모든 시스템을 관리하는 것이 좋습니다. 구독 또는 리소스 그룹 수준과 같은 다양한 수준에서 이러한 그룹을 정의할 수 있습니다.

또한 조직은 SAP 환경에서 리소스를 그룹화하면서 보안 및 정책 구조를 고려해야 합니다. 그러나 SAP 전송이 개발, 테스트, 품질 및 프로덕션 환경 간에 흐르려면 조직에 다음이 필요할 수 있습니다.

• 가상 네트워크 피어링.
• 가상 네트워크 간의 방화벽 포트 열기
• UDR 및 NSG(네트워크 보안 그룹) 규칙

서로 다른 가상 네트워크에 있는 SAP 시스템의 DBMS(데이터베이스 관리 시스템) 및 애플리케이션 계층을 호스트하고 가상 네트워크 피어링을 사용하여 연결하는 것은 권장되지 않습니다. 계층 간의 과도한 네트워크 트래픽으로 인해 상당한 비용이 발생할 수 있습니다.

SAP 구현을 위한 추가 권장 사항:

• 두 토폴로지 모두 피어되지 않은 다른 Azure 가상 네트워크에 SAP 애플리케이션 계층 및 SAP DBMS를 배치하는 것을 지원하지 않습니다.

• ASG(애플리케이션 보안 그룹) 및 NSG 규칙을 사용하여 SAP 애플리케이션과 DBMS 계층 간에 네트워크 보안 액세스 제어 목록을 정의할 수 있습니다. ASG에 가상 머신을 추가하여 보안을 관리할 수 있습니다.

• SAP 애플리케이션 및 DBMS 계층에서 사용하는 가상 머신에서 Azure 가속 네트워킹을 사용하도록 설정합니다. 다음 운영 체제 수준은 Azure에서 가속화된 네트워킹을 지원합니다.

  • Windows Server 2012 R2 이상
  • SUSE Linux Enterprise Desktop 12 SP3 이상
  • Red Hat Enterprise Linux 7.4 이상
  • Oracle Linux 7.5
    • Red Hat Enterprise Linux와 호환되는 커널에는 릴리스 3.10.0-862.13.1.el7이 필요합니다.
    • Oracle Unbreakable Enterprise 커널에는 릴리스 5가 필요합니다.

• 직접 서버 반환 기능을 사용하도록 Azure Load Balancer에 대한 내부 배포를 설정했는지 확인합니다. 이 기능은 DBMS 계층의 고가용성 구성에 내부 부하 분산 장치 구성을 사용하는 경우 대기 시간을 줄입니다.

• Linux 게스트 운영 체제에서 Load Balancer를 사용하는 경우 Linux 네트워크 매개 변수 net.ipv4.tcp_timestamps 가 로 설정되어 있는지 확인합니다 0.

• SAP 애플리케이션의 네트워크 대기 시간을 최적화하려면 Azure 근접 배치 그룹을 사용하는 것이 좋습니다.

• 마이그레이션 프로젝트의 경우 네트워크 매개 변수를 조정하는 것이 좋습니다. 예를 들어 마이그레이션 기간 동안 승인을 사용하지 않도록 설정하여 성능을 향상시킬 수 있습니다.

• SAP 지원 포털 및 SAP Note 2391465를 살펴보고 SAP 구현에 대해 자세히 알아보세요.

RISE 구현에 대한 디자인 고려 사항

Azure에서 SAP RISE 배포를 실행하는 경우 SAP 관리 환경과 사용자 고유의 Azure 에코시스템의 통합이 가장 중요합니다. 모범 사례 및 지침에 대한 자세한 내용은 SAP RISE 관리 워크로드와 Azure 통합을 참조 하세요.

SAP RISE 구현에는 일반적으로 사이트 간 VPN 또는 가상 네트워크 피어링이라는 두 가지 연결 옵션이 있습니다. 이전 Azure 워크로드가 없는 경우 사이트 및 사이트 간의 VPN이 더 쉬운 옵션일 수 있습니다. 그러나 Azure를 전략적 플랫폼으로 채택하려는 경우 적절한 Azure 랜딩 존을 설정하고 SAP RISE 테넌트에 대한 가상 네트워크 피어링을 사용할 수 있습니다. 이러한 시나리오의 경우 Azure 랜딩 존과 같은 간소화된 랜딩 존 이 좋은 옵션일 수 있습니다. 이 즉시 사용 가능한 배포 환경은 요구 사항, 특히 가상 네트워크 매개 변수에 쉽게 적용할 수 있습니다.

SAP RISE 테넌트에 테넌트 간 가상 네트워크 피어링을 배포하려면 더 많은 작업이 필요합니다. 클래스리스 Inter-Do기본 라우팅 범위가 겹치지 않도록 가상 네트워크 아키텍처를 신중하게 계획해야 합니다. 또한 DNS를 SAP RISE 테넌트에 올바르게 피어해야 합니다.

Virtual WAN 솔루션을 설정하기로 결정하고 사이트 및 사이트 간의 VPN 또는 ExpressRoute 연결이 필요한 경우 제한 사항을 고려합니다.