SAP 마이그레이션을 위한 엔터프라이즈 규모 네트워크 토폴로지 및 연결

이 문서에서는 Microsoft Azure 및 SAP 배포 내에서 네트워킹 및 연결과 관련된 주요 디자인 고려 사항 및 모범 사례를 살펴봅니다.

IP 주소 지정 계획

다음을 보장하기 위해 Azure에서 IP 주소 지정을 계획하는 것이 중요합니다.

  • IP 주소 공간은 온-프레미스 위치와 Azure 지역 간에 겹치지 않습니다.
  • VNet(가상 네트워크)에는 올바른 주소 공간이 포함되어 있습니다.
  • 서브넷 구성에 대한 적절한 계획은 미리 발생합니다.

다음 아키텍처 다이어그램은 Azure의 SAP 구성 집합의 엔터프라이즈 규모 네트워킹 고려 사항을 보여줍니다.

Azure의 SAP 구성 집합의 엔터프라이즈 규모 네트워킹 고려 사항 다이어그램입니다.

그림 1: Azure의 SAP 구성 집합의 엔터프라이즈 규모 네트워킹 고려 사항 다이어그램

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

서브넷을 특정 서비스에만 위임한 다음 서브넷 내에서 해당 서비스의 인스턴스를 만들 수 있습니다. Azure는 VNet에서 여러 위임된 서브넷을 만드는 데 도움이 되지만 Azure NetApp Files 위해 하나의 위임된 서브넷만 VNet에 존재할 수 있습니다. Azure NetApp Files 위임된 서브넷을 두 개 이상 사용하는 경우 새 볼륨을 만들려는 시도가 실패합니다.

사용 사례:

공유 파일 시스템을 통해 SAP를 배포하는 동안 인기 있는 Azure NetApp Files 구현하려면 위임된 서브넷이 필요합니다. 위임된 서브넷은 부하 분산 또는 SAP BusinessObjects Business Intelligence, 부하 분산 SAP 웹 애플리케이션 서버와 같은 Azure Application Gateway SAP 시나리오 중에 Application Gateway 경우에만 필요합니다.

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

DNS(Domain Name System)는 전체 엔터프라이즈 규모 아키텍처에서 중요한 디자인 항목입니다. 일부 조직에서는 DNS에 대한 기존 투자를 사용할 수 있습니다. 다른 사용자는 내부 DNS 인프라를 현대화하고 네이티브 Azure 기능을 사용할 수 있는 기회로 클라우드 채택을 볼 수 있습니다.

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

다음 권장 사항은 마이그레이션 중에 가상 머신의 DNS 또는 가상 이름이 변경되지 않는 경우에 대한 것입니다.

사용 사례:

  • 백그라운드 DNS 및 가상 이름은 SAP 환경에서 많은 시스템 인터페이스를 연결하며, 고객은 개발자가 시간에 따라 정의하는 인터페이스를 인식하기도 합니다. 마이그레이션 후 가상 또는 DNS 이름이 변경될 때 다양한 시스템 간에 연결 문제가 발생하며, 이러한 유형의 문제를 방지하기 위해 DNS 별칭을 유지하는 것이 좋습니다.

  • 서로 다른 DNS 영역을 사용하여 각 환경(샌드박스, 개발, 사전 프로덕션 및 프로덕션)을 서로 구분합니다. 단, 자체 VNet이 있는 SAP 배포의 경우는 예외입니다. 여기서는 프라이빗 DNS 영역이 필요하지 않을 수 있습니다.

Azure 네트워크 토폴로지 정의

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

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

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

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

조직에서 허브 및 스포크 아키텍처를 기반으로 하는 기존 Azure 네트워크 토폴로지 사용:

  • 선택한 Azure 지역에만 리소스를 배포할 계획
  • 상호 연결된 글로벌 네트워크가 필요하지 않습니다.
  • 지역당 원격 또는 분기 위치가 거의 없으며 30개 미만의 IP 보안(IPsec) 터널이 필요합니다.
  • Azure 네트워크를 수동으로 구성하려면 모든 권한과 세분성이 필요합니다.

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

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

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

  • Virtual WAN 가상 WAN 기반 토폴로지용 스포크 VNet 간의 연결(UDR(사용자 정의 라우팅) 또는 NLA를 설정할 필요가 없음)을 관리하고 동일한 가상 허브에서 VNet 간 트래픽에 대한 최대 네트워크 처리량은 초당 50기가비트입니다. 필요한 경우 SAP 랜딩 존은 VNet 피어링을 사용하여 다른 랜딩 존에 연결하고 이 대역폭 제한을 극복합니다.

  • SAP 애플리케이션과 데이터베이스 서버 간에 NLA를 배포하는 것은 지원되지 않습니다.

  • 로컬 및 글로벌 VNet 피어링이 연결을 제공하며, 여러 Azure 지역에 걸쳐 SAP 배포를 위한 랜딩 존 간의 연결을 보장하는 기본 접근 방식입니다.

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

이 섹션에서는 공용 인터넷과 인바운드 및 아웃바운드 연결을 위한 연결 모델을 권장합니다. Azure 방화벽, Application Gateway의 azure 웹 응용 프로그램 방화벽, azure Front 도어 등의 azure 기본 네트워크 보안 서비스는 완전히 관리 되는 서비스 이므로 인프라 배포와 관련 된 운영 및 관리 비용이 발생 하지 않으며,이는 대규모로 복잡 해질 수 있습니다.

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

  • 전 세계 공간을 사용 하는 고객의 경우 azure Front 도어가 Azure 웹 응용 프로그램 방화벽 정책을 사용 하 여 SAP 배포를 통해 azure 지역에 걸쳐 전역 HTTP/S 응용 프로그램을 제공 하 고 보호 합니다.

  • 이 서비스를 사용 하 고 Application Gateway 하 여 HTTP/S 응용 프로그램을 보호 하는 경우 Azure Front 도어에서 웹 응용 프로그램 방화벽 정책을 활용 하세요. Azure Front 도어의 트래픽만 받으려면 Application Gateway를 잠급니다.

  • Application Gateway 및 웹 응용 프로그램 방화벽은 Application Gateway, SAP 웹 디스패처 및 타사 서비스인 NetScaler의 비교와 같이 Application Gateway SAP 웹 앱에 대 한 역방향 프록시로 사용 되는 경우 제한 사항이 있습니다.

SAP 웹 디스패처 및 NetScaler는 Application Gateway 보다 지능적 이므로이 서비스로 교체 하려면 광범위 한 테스트가 필요 합니다. 가능한 경우 최신 상태를 확인 하 고 지원 되거나 지원 되지 않는 (테스트/테스트 되지 않은) 시나리오를 모두 나열 합니다.

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

  • 데이터 누출을 방지 하기 위해 Azure 개인 링크를 사용 하 여 Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2, Azure Data Factory 등의 서비스 리소스로 플랫폼에 안전 하 게 액세스할 수 있습니다. 또한 Azure 개인 끝점은 Azure Storage, Azure Backup 등과 같은 Vnet와 서비스 간의 트래픽을 보호 하는 데 도움이 될 수 있습니다. VNet과 프라이빗 엔드포인트 사용 서비스 간의 트래픽은 Microsoft 글로벌 네트워크를 통해 이동하므로 공용 인터넷에 노출되지 않습니다.

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

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

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

  • 프라이빗 피어링을 구성하는 데 Azure ExpressRoute 사용하는 경우 트래픽은 현재 암호화되지 않습니다.

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

  • SAP 트래픽을 암호화해야 하는지 여부는 고객이 결정해야 합니다. 네트워크 토폴로지 및 연결을 탐색하여 엔터프라이즈 규모 랜딩 존의 네트워크 암호화 옵션을 이해합니다.

시스템 분리

개발, 테스트, 품질, 사전 프로덕션, 프로덕션 등과 같은 다양한 환경이 SAP 시나리오에 존재하기 때문에 고객은 보안 및 규정 준수 표준을 준수하기 위해 이러한 시스템을 논리적/물리적 구문으로 분류하는 경향이 있습니다. 하나의 공통 리소스 그룹에서 동일한 수명 주기를 가진 모든 시스템을 관리하는 것이 좋습니다. 그룹화는 구독 또는 리소스 그룹 수준과 같은 다양한 수준에서 정의할 수 있습니다. 또한 조직은 SAP 환경에서 리소스를 그룹화하면서 보안 및 정책 구조를 고려해야 합니다. 그러나 SAP 전송이 개발, 테스트, 품질 및 프로덕션 간에 흐르려면 조직에 다음이 필요할 수 있습니다.

  • VNet 피어링 및 관련 비용
  • VNet 간의 방화벽 포트 열기
  • UDR 및 NSG(네트워크 보안 그룹) 규칙

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

SAP 구현에 대 한 추가 권장 사항:

  • SAP 응용 프로그램 계층 및 SAP DBMS를 피어 링가 아닌 다른 Azure Vnet에 배치 하는 것은 지원 되지 않습니다.

  • ASG (응용 프로그램 보안 그룹) 및 NSG 규칙을 사용 하 여 SAP 응용 프로그램 및 DBMS 계층 간의 네트워크 보안 액세스 제어 목록을 정의할 수 있습니다. ASGs는 보안을 관리 하는 데 도움이 되는 가상 머신을 그룹화 합니다.

  • SAP 응용 프로그램 및 DBMS 계층에 사용 되는 Vm에서 Azure 가속화 된 네트워킹을 사용 하도록 설정 했는지 확인 합니다. Azure에서 다양 한 운영 체제 수준이 가속화 된 네트워킹을 지 원하는 것을 고려 합니다.

    • Windows Server 2012 R2 이상
    • SUSE Linux 12 SP3 이상
    • Red Hat Enterprise Linux 7.4 이상
    • Oracle Linux 7.5: Red Hat Enterprise Linux와 호환 되는 커널에는 Release 3.10.0-862.13.1가 필요 합니다. Oracle Unbreakable Enterprise 커널에는 릴리스 5가 필요 합니다.
  • Azure Load Balancer에 대 한 내부 배포가 DSR (Direct Server Return)을 사용 하도록 설정 되어 있는지 확인 합니다. 이 설정은 DBMS 계층의 고가용성 구성에 내부 부하 분산 장치 구성을 사용 하는 경우 대기 시간을 줄입니다.

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

  • SAP 응용 프로그램의 네트워크 대기 시간을 최적화 하려면 Azure 근접 배치 그룹을 사용 하는 것이 좋습니다.

  • Sap 지원 포털sap Note 2391465 을 탐색 하 여 sap 구현에 대해 자세히 알아보세요.