다음을 통해 공유

Azure에서 SAP 배포 계획 및 구현

  • 아티클

Azure에서 조직은 긴 조달 주기를 완료하지 않고 필요한 클라우드 리소스 및 서비스를 가져올 수 있습니다. 그러나 Azure에서 SAP 워크로드를 실행하려면 사용 가능한 옵션에 대한 지식과 솔루션을 구동할 Azure 구성 요소 및 아키텍처를 선택하기 위한 신중한 계획이 필요합니다.

Azure는 SAP 애플리케이션을 실행하기 위한 포괄적인 플랫폼을 제공합니다. Azure IaaS(Infrastructure as a Service) 및 PaaS(Platform as a Service) 제품은 결합되어 전체 SAP 엔터프라이즈 환경을 성공적으로 배포하기 위한 최적의 선택을 제공합니다.

이 문서에서는 AZURE 및 기타 플랫폼에 SAP 소프트웨어를 설치하고 배포하는 방법에 대한 정보를 위한 기본 원본인 SAP 설명서 및 SAP Notes를 보완합니다.

정의

이 문서 전체에서는 다음 용어를 사용합니다.

  • SAP 구성 요소: SAP S/4HANA, SAP ECC, SAP BW 또는 SAP Solution Manager와 같은 개별 SAP 애플리케이션입니다. SAP 구성 요소는 기존의 ABAP(Advanced Business Application Programming) 또는 Java 기술을 기반으로 하거나 SAP BusinessObjects와 같은 SAP NetWeaver를 기반으로 하지 않는 애플리케이션일 수 있습니다.
  • SAP 환경: 개발, 품질 보증, 교육, 재해 복구 또는 프로덕션과 같은 비즈니스 기능을 수행하기 위해 논리적으로 그룹화된 여러 SAP 구성 요소입니다.
  • SAP 환경: 조직의 IT 환경에서 SAP 자산의 전체 집합입니다. SAP 환경에는 모든 프로덕션 및 비프로덕션 환경이 포함됩니다.
  • SAP 시스템: DBMS(데이터베이스 관리 시스템) 계층과 애플리케이션 계층의 조합입니다. 두 가지 예는 SAP ERP 개발 시스템과 SAP BW 테스트 시스템입니다. Azure 배포에서는 이러한 두 계층을 온-프레미스와 Azure 간에 배포할 수 없습니다. SAP 시스템은 온-프레미스 또는 Azure에 배포되어야 합니다. 그러나 Azure 또는 온-프레미스에는 SAP 지형 내의 서로 다른 시스템을 운영할 수 있습니다.

리소스

Azure에서 SAP 워크로드를 호스트하고 실행하는 방법을 설명하는 설명서의 진입점은 Azure 가상 머신에서 SAP를 시작하는 것입니다. 이 문서에서는 다음을 다루는 다른 문서에 대한 링크를 찾을 수 있습니다.

  • 스토리지, 네트워킹 및 지원되는 옵션에 대한 SAP 워크로드 관련 사항.
  • Azure의 다양한 DBMS 시스템에 대한 SAP DBMS 가이드.
  • 수동 및 자동화된 SAP 배포 가이드.
  • Azure의 SAP 워크로드에 대한 고가용성 및 재해 복구 세부 정보.
  • 다른 서비스 및 타사 애플리케이션과 Azure의 SAP의 통합.

Important

필수 구성 요소, 설치 프로세스 및 특정 SAP 기능에 대한 세부 정보는 SAP 설명서 및 가이드를 주의 깊게 읽어야 합니다. 이 문서에서는 Azure VM(가상 머신)에서 설치 및 작동하는 SAP 소프트웨어에 대한 특정 작업만 다룹니다.

다음 SAP 노트는 SAP 배포에 대한 Azure 지침의 기반을 형성합니다.

Note 번호 타이틀
1928533 Azure의 SAP 애플리케이션: 지원 제품 및 크기 조정
2015553 Azure의 SAP: 필수 구성 요소 지원
2039619 Oracle Database를 사용하는 Azure의 SAP 애플리케이션
2233094 DB6: Linux, UNIX 및 Windows용 IBM DB2를 사용하는 Azure의 SAP 애플리케이션
1999351 SAP용 고급 Azure 모니터링 문제 해결
1409604 Windows에서의 가상화: 향상된 모니터링
2191498 Azure와 Linux의 SAP: 향상된 모니터링
2731110 Azure에서 SAP용 NVA(네트워크 가상 어플라이언스) 지원

Azure 구독 및 리소스의 일반적인 기본 및 최대 제한 사항은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.

시나리오

SAP 서비스는 종종 기업에서 가장 중요 업무용 애플리케이션으로 간주됩니다. 애플리케이션의 아키텍처 및 작업은 복잡하며 가용성 및 성능에 대한 모든 요구 사항을 충족하는지 확인하는 것이 중요합니다. 엔터프라이즈는 일반적으로 비즈니스에 중요한 비즈니스 프로세스를 실행할 클라우드 공급자를 신중하게 생각합니다.

Azure는 비즈니스에 중요한 SAP 애플리케이션과 비즈니스 프로세스에 이상적인 퍼블릭 클라우드 플랫폼입니다. SAP NetWeaver 및 SAP S/4HANA 시스템을 비롯한 대부분의 최신 SAP 소프트웨어는 현재 Azure 인프라에서 호스팅할 수 있습니다. Azure는 800개 이상의 CPU 유형과 테라바이트의 메모리가 있는 VM을 제공합니다.

지원되는 시나리오 및 지원되지 않는 일부 시나리오에 대한 설명은 Azure의 SAP VM 지원 시나리오를 참조하세요. Azure에 배포하려는 아키텍처를 계획할 때 지원되지 않는 것으로 표시된 이러한 시나리오 및 조건을 확인합니다.

Azure IaaS 또는 일반적인 IaaS에 SAP 시스템을 성공적으로 배포하려면 전형적인 프라이빗 클라우드 및 IaaS 제품 간의 주요 차이점을 이해해야 합니다. 기존 호스트 또는 아웃소싱업체는 인프라(네트워크, 스토리지 및 서버 유형)를 고객이 호스트하려는 워크로드에 맞게 조정합니다. IaaS 배포에서 잠재적인 워크로드를 평가하고 VM, 스토리지 및 네트워크의 올바른 Azure 구성 요소를 선택하는 것은 고객 또는 파트너의 책임입니다.

Azure에 배포를 계획하기 위한 데이터를 수집하려면 다음을 수행해야 합니다.

  • Azure에서 지원되는 SAP 제품 및 버전을 결정합니다.
  • 사용하려는 운영 체제 릴리스가 SAP 제품에 대해 선택할 Azure VM에서 지원되는지 여부를 평가합니다.
  • SAP 제품에 대해 지원되는 특정 VM의 DBMS 릴리스를 결정합니다.
  • 지원되는 구성을 달성하기 위해 필요한 운영 체제 및 DBMS 릴리스에 맞게 SAP 환경을 업그레이드하거나 업데이트해야 하는지 평가합니다.
  • Azure에 배포하려면 다른 운영 체제로 바꾸어야 하는지 평가

Azure에서 지원되는 SAP 구성 요소, Azure 인프라 단위 및 관련 운영 체제 릴리스, DBMS 릴리스에 대한 자세한 내용은 Azure 배포에서 지원되는 SAP 소프트웨어에 설명되어 있습니다. SAP 릴리스, 운영 체제 릴리스 및 DBMS 릴리스 간의 지원 및 종속성을 평가하여 얻은 지식은 SAP 시스템을 Azure로 이동하려는 노력에 상당한 영향을 미칩니다. 예를 들어 SAP 릴리스를 업그레이드하거나 다른 운영 체제로 전환해야 하는지와 같이 상당한 준비 작업이 관련되어 있는지 알아봅니다.

배포를 계획하는 첫 번째 단계

배포 계획의 첫 번째 단계는 SAP 애플리케이션을 실행하는 데 사용할 수 있는 VM을 찾는 것이 아닙니다.

배포를 계획하는 첫 번째 단계는 조직의 규정 준수 및 보안 팀과 협력하여 퍼블릭 클라우드에서 SAP 워크로드 또는 비즈니스 프로세스 유형을 배포하기 위한 경계 조건을 결정하는 것입니다. 프로세스는 시간이 오래 걸릴 수 있지만 완료하는 것이 중요합니다.

조직에서 이미 Azure에 소프트웨어를 배포한 경우 프로세스가 쉬울 수 있습니다. 이 과정을 처음 시작하는 것에 가깝다면 특정 SAP 데이터와 SAP 비즈니스 프로세스를 퍼블릭 클라우드에서 호스팅하기 위한 경계 조건, 보안 조건 및 엔터프라이즈 아키텍처를 알아내는 데 더욱 광범위한 논의가 필요할 수 있습니다.

규정 준수 계획

규정 준수 요구 사항을 계획하는 데 도움이 되는 Microsoft 규정 준수 제품 목록은 Microsoft 규정 준수 제안을 참조하세요.

보안 계획

미사용 데이터에 대한 데이터 암호화 또는 Azure 서비스의 다른 암호화와 같은 SAP 관련 보안 문제에 대한 자세한 내용은 Azure 암호화 개요 및 SAP 환경에 대한 보안을 참조하세요.

Azure 리소스 구성

보안 및 규정 준수 검토와 함께 이 작업을 아직 수행하지 않은 경우 Azure 리소스를 구성하는 방법을 계획합니다. 이 프로세스에는 다음에 대한 의사 결정이 포함됩니다.

  • VM 및 리소스 그룹과 같이 각 Azure 리소스에 사용하는 명명 규칙.
  • SAP 워크로드에 대한 구독 및 관리 그룹 디자인(예: 워크로드당, 배포 계층별 또는 각 사업부에 대해 여러 구독을 만들어야 하는지 여부).
  • 구독 및 관리 그룹에 대한 Azure Policy의 엔터프라이즈 수준 사용.

올바른 결정을 내릴 수 있도록 엔터프라이즈 아키텍처의 많은 세부 정보는 Azure 클라우드 채택 프레임워크에 설명되어 있습니다.

프로젝트에서 계획의 첫 단계를 간과해서는 안 됩니다. 규정 준수, 보안 및 Azure 리소스 조직에 대한 계약 및 규칙이 있는 경우에만 배포 계획을 진행해야 합니다.

다음 단계는 Azure에서 배포하는 지리적 배치 및 네트워크 아키텍처를 계획하는 것입니다.

Azure 지리 및 지역

Azure 서비스는 별도의 Azure 지역 내에서 사용할 수 있습니다. Azure 지역은 데이터 센터의 컬렉션입니다. 데이터 센터에는 해당 지역에서 사용할 수 있는 Azure 서비스를 호스트하고 실행하는 하드웨어 및 인프라가 포함되어 있습니다. 이 인프라에는 컴퓨팅 노드 또는 스토리지 노드로 기능하거나 네트워크 기능을 실행하는 대량의 노드가 포함됩니다.

Azure 지역 목록은 Azure 지역을 참조하세요. 대화형 맵은 Azure 글로벌 인프라를 참조하세요.

모든 Azure 지역이 동일한 서비스를 제공하는 것은 아닙니다. 실행하려는 SAP 제품, 크기 조정 요구 사항 및 필요한 운영 체제 및 DBMS에 따라 특정 지역에서 시나리오에 필요한 VM 유형을 제공하지 않을 수 있습니다. 예를 들어 SAP HANA를 실행하는 경우 일반적으로 다양한 M 시리즈 VM 제품군의 VM이 필요합니다. 이러한 VM 제품군은 Azure 지역의 하위 집합에만 배포됩니다.

주 지역 및 최종적으로 보조 지역으로 선택할 지역을 계획하고 생각할 때 시나리오에 필요한 서비스를 고려 중인 지역에서 사용할 수 있는지 여부를 조사해야 합니다. 각 지역에서 사용할 수 있는 VM 유형, Azure 스토리지 유형 및 기타 Azure 서비스는 지역별 사용 가능 제품에서 정확하게 알아볼 수 있습니다.

Azure 쌍을 이루는 지역

Azure 쌍을 이루는 지역에서는 기본적으로 두 지역 간에 특정 데이터의 복제가 사용하도록 설정됩니다. 자세한 내용은 Azure의 지역 간 복제: 비즈니스 연속성 및 재해 복구를 참조하세요.

지역 쌍의 데이터 복제는 쌍을 이루는 지역에 복제하도록 구성할 수 있는 Azure Storage 유형에 연결됩니다. 자세한 내용은 보조 지역의 스토리지 중복성을 참조하세요.

쌍을 이루는 지역 데이터 복제를 지원하는 스토리지 유형은 SAP 구성 요소 및 DBMS 워크로드에 적합하지 않은 스토리지 유형 입니다. Azure Storage 복제는 Azure Blob Storage(백업 목적), 파일 공유 및 볼륨, 기타 대기 시간이 긴 스토리지 시나리오에만 유용합니다.

주 또는 보조 지역에서 사용하려는 쌍을 이루는 지역 및 서비스를 확인하면 주 지역에서 사용하려는 Azure 서비스 또는 VM 유형을 보조 지역으로 사용하려는 쌍을 이루는 지역에서 사용할 수 없을 수 있습니다. 또는 데이터 준수 이유로 인해 Azure 쌍을 이루는 지역이 시나리오에 적합하지 않다고 판단할 수 있습니다. 이러한 시나리오의 경우 보조 또는 재해 복구 지역으로 비계층 지역을 사용해야 하며 일부 데이터 복제를 직접 설정해야 합니다.

가용성 영역

많은 Azure 지역은 가용성 영역을 사용하여 Azure 지역 내의 위치를 물리적으로 구분합니다. 각 가용성 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다. 가용성 영역을 사용하여 복원력을 향상시키는 예제는 Azure의 두 개별 가용성 영역에 두 개의 VM을 배포하는 것입니다. 또 다른 예는 한 가용성 영역에서 SAP DBMS 시스템에 대한 고가용성 프레임워크를 구현하고 다른 가용성 영역에 SAP(A)SCS를 배포하여 Azure에서 최상의 SLA를 얻는 것입니다.

Azure의 VM SLA에 대한 자세한 내용은 최신 버전의 가상 머신 SLA를 확인하세요. Azure 지역은 빠르게 개발되고 확장되므로 Azure 지역의 토폴로지, 물리적 데이터 센터 수, 데이터 센터 간 거리 및 Azure 가용성 영역 간의 거리가 진화합니다. 인프라가 변경됨에 따라 네트워크 대기 시간이 변경됩니다.

가용성 영역이 있는 지역을 선택할 때 Azure 가용성 영역을 사용하여 SAP 워크로드 구성의 지침을 따릅니다. 또한 요구 사항, 선택한 지역 및 워크로드에 가장 적합한 영역 배포 모델을 결정합니다.

장애 도메인

장애 도메인은 실제 오류 단위를 나타냅니다. 장애 도메인은 데이터 센터에 포함된 물리적 인프라와 밀접한 관련이 있습니다. 실제 블레이드 또는 랙은 장애 도메인으로 간주될 수 있지만 물리적 컴퓨팅 요소와 장애 도메인 간에는 직접 일대일 매핑이 없습니다.

하나의 SAP 시스템의 일부로 여러 VM을 배포하는 경우 가용성 SLA에 대한 요구 사항을 충족할 수 있도록 Azure 패브릭 컨트롤러에 간접적으로 영향을 미하여 VM을 다른 장애 도메인에 배포할 수 있습니다. 그러나 Azure 배율 단위(수백 개의 Compute 노드 또는 Storage 노드 및 네트워킹 컬렉션)에 장애 도메인을 배포하거나 특정 장애 도메인에 VM을 할당하는 것은 직접 제어할 수 없습니다. Azure 패브릭 컨트롤러가 여러 다른 장애 도메인에 VM 집합을 배포하도록 하려면 배포 시에 Azure 가용성 집합을 VM에 할당해야 합니다. 자세한 내용은 가용성 집합을 참조하세요.

업데이트 도메인

업데이트 도메인은 여러 VM으로 구성된 SAP 시스템의 VM을 업데이트하는 방법을 설정하는 논리 단위를 나타냅니다. 플랫폼 업데이트가 발생하면 Azure는 이러한 업데이트 도메인을 하나씩 업데이트하는 프로세스를 진행합니다. 배포 시에 여러 업데이터 도메인에 VM을 분산하여 잠재적인 가동 중지 시간으로부터 SAP 시스템을 보호할 수 있습니다. 장애 도메인과 마찬가지로 Azure 배율 단위는 여러 업데이트 도메인으로 나뉩니다. Azure 패브릭 컨트롤러가 여러 다른 업데이트 도메인에 VM 집합을 배포하도록 하려면 배포 시에 Azure 가용성 집합을 VM에 할당해야 합니다. 자세한 내용은 가용성 집합을 참조하세요.

업데이트 도메인 및 실패 도메인을 보여 주는 다이어그램

가용성 집합

단일 Azure 가용성 집합 내의 Azure VM은 Azure 패브릭 컨트롤러에 의해 여러 장애 도메인에 배포됩니다. 다른 장애 도메인에 대한 배포는 인프라 유지 관리 중에 또는 하나의 장애 도메인에서 오류가 발생하는 경우 SAP 시스템의 모든 VM이 종료되지 않도록 하는 것입니다. 기본적으로 VM은 가용성 집합에 속하지 않습니다. 배포 시 또는 VM이 다시 배포될 때만 가용성 집합에 VM을 추가할 수 있습니다.

Azure 가용성 집합 및 가용성 집합이 장애 도메인과 어떻게 관련되는지에 대한 자세한 내용은 Azure 가용성 집합을 참조하세요.

Important

Azure의 가용성 영역 및 가용성 집합은 상호 배타적입니다. 특정 가용성 영역 또는 가용성 집합에 여러 VM을 배포할 수 있습니다. 그러나 가용성 영역과 가용성 집합을 모두 VM에 할당할 수 있는 것은 아닙니다.

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

가용성 집합을 정의하고 하나의 가용성 집합에서 VM 제품군이 다른 여러 VM을 혼합하려고 할 경우, 특정 VM 유형을 가용성 집합에 포함하지 못하는 문제가 발생할 수 있습니다. 그 이유는 가용성 집합이 특정 유형의 컴퓨팅 호스트를 포함하는 배율 단위에 묶여 있기 때문입니다. 특정 유형의 컴퓨팅 호스트는 특정 유형의 VM 패밀리에서만 실행할 수 있습니다.

예를 들어 가용성 집합을 만들고 가용성 집합에 첫 번째 VM을 배포합니다. 가용성 집합에 추가하는 첫 번째 VM은 Edsv5 VM 제품군에 있습니다. M 제품군에 있는 VM인 두 번째 VM을 배포하려고 하면 이 배포가 실패합니다. 그 이유는 Edsv5 제품군 VM이 M 제품군의 VM과 동일한 호스트 하드웨어에서 실행되지 않기 때문입니다.

VM 크기를 조정하는 경우에도 동일한 문제가 발생할 수 있습니다. VM을 Edsv5 제품군에서 M 제품군에 있는 VM 유형으로 이동하려고 하면 배포가 실패합니다. 동일한 호스트 하드웨어에서 호스팅할 수 없는 VM 제품군의 크기를 조정할 경우, 가용성 집합에서 모든 VM을 정지하고 크기를 조정해야 다른 호스트 컴퓨터 유형에서 실행할 수 있습니다. 가용성 집합에 배포된 VM의 SLA에 대한 자세한 내용은 가상 머신 SLA를 참조하세요.

유연한 오케스트레이션을 갖춘 가상 머신 확장 집합

유연한 오케스트레이션 기능을 갖춘 가상 머신 확장 집합은 플랫폼 관리되는 가상 머신의 논리적 그룹화를 제공합니다. 지역 내에서 확장 집합을 만들거나 가용성 영역에 걸쳐 확장할 수 있는 옵션이 있습니다. platformFaultDomainCount>1(FD>1)이 있는 지역 내에서 유연한 확장 집합을 만들 때 확장 집합에 배포된 VM은 동일한 지역의 지정된 수의 장애 도메인에 분산됩니다. 반면에 platformFaultDomainCount=1(FD=1)을 사용하여 가용성 영역에 걸쳐 유연한 확장 집합을 만들면 지정된 영역에 VM을 분산하고 확장 집합은 최상의 노력으로 영역 내의 여러 장애 도메인에 VM을 분산합니다.

SAP 워크로드의 경우 FD=1이 있는 유연한 확장 집합만 지원됩니다. 기존 가용성 영역 배포 대신 영역 간 배포에 FD=1과 함께 유연한 확장 집합을 사용할 경우의 이점은 확장 집합과 함께 배포된 VM이 최상의 방식으로 영역 내의 여러 장애 도메인에 분산된다는 점입니다. 확장 집합을 사용한 SAP 워크로드 배포에 대해 자세히 알아보려면 유연한 가상 머신 규모 배포 가이드를 참조하세요.

Azure에서 고가용성 SAP 워크로드를 배포할 때는 사용 가능한 다양한 배포 유형과 다양한 Azure 지역(예: 영역 간, 단일 영역 또는 영역이 없는 지역)에 적용할 수 있는 방법을 고려해야 합니다. 자세한 내용은 SAP 워크로드에 대한 고가용성 배포 옵션을 참조하세요.

팁

현재 가용성 집합 또는 가용성 영역에 배포된 SAP 워크로드를 FD=1로 유연하게 확장할 수 있는 직접적인 방법은 없습니다. 전환하려면 기존 리소스의 영역 제약 조건이 있는 VM 및 디스크를 다시 만들어야 합니다. 오픈 소스 프로젝트에는 가용성 집합 또는 가용성 영역에 배포된 VM을 FD=1을 사용하는 유연한 확장 집합으로 변경하는 샘플로 사용할 수 있는 PowerShell 함수가 포함되어 있습니다. 블로그 게시물에서는 가용성 집합 또는 가용성 영역에 배포된 HA 또는 비 HA SAP 시스템을 FD=1을 사용하는 유연한 확장 집합으로 수정하는 방법을 보여줍니다.

근접 배치 그룹

개별 SAP VM 간의 네트워크 대기 시간은 성능에 상당한 영향을 미칠 수 있습니다. SAP 애플리케이션 서버와 DBMS 간의 네트워크 왕복 시간은 특히 비즈니스 애플리케이션에 상당한 영향을 미칠 수 있습니다. 최적으로 SAP VM을 실행하는 모든 컴퓨팅 요소는 가능한 한 밀접하게 배치됩니다. 이 옵션은 모든 조합에서 가능하지 않으며 Azure는 어떤 VM을 함께 유지할지 모를 수 있습니다. 대부분의 상황 및 지역에서 기본 배치는 네트워크 왕복 대기 시간 요구 사항을 충족합니다.

기본 배치가 SAP 시스템 내의 네트워크 왕복 요구 사항을 충족하지 않는 경우 근접 배치 그룹이 이러한 요구를 해결할 수 있습니다. Azure 지역, 가용성 영역 및 가용성 집합의 위치 제약 조건과 함께 근접 배치 그룹을 사용하여 복원력을 높일 수 있습니다. 근접 배치 그룹을 사용하면 가용성 영역과 가용성 집합을 결합하는 동시에 다른 업데이트 및 실패 도메인을 설정할 수 있습니다. 근접 배치 그룹에는 단일 SAP 시스템만 포함되어야 합니다.

근접 배치 그룹에 배포하면 대기 시간 최적화 배치가 가장 많을 수 있지만 근접 배치 그룹을 사용하여 배포하면 단점이 있습니다. 일부 VM 패밀리는 하나의 근접 배치 그룹에서 결합할 수 없거나 VM 패밀리 간에 크기를 조정하는 경우 문제가 발생할 수 있습니다. VM 제품군, 지역 및 가용성 영역의 제약 조건은 공동 배치를 지원하지 않을 수 있습니다. 자세한 내용 및 근접 배치 그룹 사용의 이점 및 잠재적인 문제에 대해 알아보려면 근접 배치 그룹 시나리오를 참조하세요.

근접 배치 그룹을 사용하지 않는 VM은 SAP 시스템의 대부분의 경우 기본 배포 방법이어야 합니다. 이 기본값은 SAP 시스템의 영역(단일 가용성 영역) 및 영역 간(두 가용성 영역 간에 분산된 VM) 배포의 경우 특히 그렇습니다. 근접 배치 그룹 사용은 성능상의 이유로만 필요한 경우 SAP 시스템 및 Azure 지역으로 제한해야 합니다.

Azure 네트워킹

Azure에는 SAP 배포에서 구현할 수 있는 모든 시나리오에 매핑되는 네트워크 인프라가 있습니다. Azure에는 다음과 같은 기능이 있습니다.

  • Azure 서비스에 액세스하고 애플리케이션에서 사용하는 VM의 특정 포트에 대한 액세스.
  • 관리 및 관리를 위해 SSH(Secure Shell) 또는 Windows RDP(원격 데스크톱)를 통해 VM에 대한 직접 액세스.
  • VM과 Azure 서비스 간의 내부 통신 및 이름 확인.
  • 온-프레미스 네트워크와 Azure 네트워크 간의 온-프레미스 연결.
  • 다른 Azure 지역에 배포된 서비스 간 통신.

네트워킹에 대한 자세한 내용은 Azure Virtual Network를 참조하세요.

네트워킹 디자인은 일반적으로 Azure에 배포할 때 수행하는 첫 번째 기술 활동입니다. SAP와 같은 중앙 엔터프라이즈 아키텍처를 자주 지원하는 것은 전체 네트워킹 요구 사항의 일부입니다. 계획 단계에서 제안된 네트워킹 아키텍처를 최대한 자세히 문서화해야 합니다. 서브넷 네트워크 주소 변경과 같이 나중에 변경하는 경우 배포된 리소스를 이동하거나 삭제해야 할 수 있습니다.

Azure 가상 네트워크

가상 네트워크는 Azure에서 프라이빗 네트워크의 기본 구성 요소입니다. 네트워크의 주소 범위를 정의하고 범위를 네트워크 서브넷으로 구분할 수 있습니다. 네트워크 서브넷은 SAP VM에서 사용할 수 있거나 특정 서비스 또는 용도에 전용으로 사용할 수 있습니다. Azure Virtual Network 및 Azure Application Gateway와 같은 일부 Azure 서비스에는 전용 서브넷이 필요합니다.

가상 네트워크는 네트워크 경계 역할을 합니다. 배포를 계획할 때 필요한 디자인의 일부는 가상 네트워크, 서브넷 및 프라이빗 네트워크 주소 범위를 정의하는 것입니다. VM이 배포된 후에는 VM에 대한 NIC(네트워크 인터페이스 카드)와 같은 리소스에 대한 가상 네트워크 할당을 변경할 수 없습니다. 가상 네트워크 또는 서브넷 주소 범위를 변경하려면 배포된 모든 리소스를 다른 서브넷으로 이동해야 할 수 있습니다.

네트워크 디자인은 SAP 배포에 대한 몇 가지 요구 사항을 해결해야 합니다.

  • 방화벽과 같은 네트워크 가상 어플라이언스는 SAP 커널(예: S/4HANA 또는 SAP NetWeaver)을 통해 SAP 애플리케이션과 SAP 제품의 DBMS 계층 간의 통신 경로에 배치되지 않습니다.
  • 네트워크 라우팅 제한은 서브넷 수준의 NSG(네트워크 보안 그룹)에 의해 적용됩니다. VM의 IP를 NSG 규칙에서 유지 관리되는 ASG(애플리케이션 보안 그룹)로 그룹화하고 권한의 역할, 계층 및 SID 그룹을 제공합니다.
  • SAP 애플리케이션 및 데이터베이스 VM은 단일 가상 네트워크의 동일하거나 다른 서브넷 내에서 동일한 가상 네트워크에서 실행됩니다. 애플리케이션 및 데이터베이스 VM에 다른 서브넷을 사용합니다. 또는 전용 애플리케이션 및 DBMS ASG를 사용하여 동일한 서브넷 내의 각 워크로드 유형에 적용되는 규칙을 그룹화합니다.
  • 가속화된 네트워킹은 기술적으로 가능한 SAP 워크로드에 대한 모든 VM의 모든 네트워크 카드에서 사용하도록 설정됩니다.
  • 이름 확인(DNS), ID 관리(Windows Server Active Directory 도메인/Microsoft Entra ID) 및 관리 액세스를 포함하여 중앙 서비스에 대한 종속성에 대한 보안 액세스를 보장합니다.
  • 필요에 따라 퍼블릭 엔드포인트에 대한 액세스를 제공합니다. 고가용성에서 ClusterLabs Pacemaker 작업을 위한 Azure 관리 또는 Azure Backup과 같은 Azure 서비스에 대한 예제가 있습니다.
  • 자체 경로 및 NSG 규칙이 있는 지정된 서브넷을 만들어야 하는 경우에만 여러 NIC를 사용합니다.

SAP 배포를 위한 네트워크 아키텍처의 예는 다음 문서를 참조하세요.

가상 네트워크 고려 사항

일부 가상 네트워킹 구성에는 알아야 할 특정 고려 사항이 있습니다.

  • S/4HANA 또는 SAP NetWeaver와 같은 SAP 커널을 사용하여 SAP 애플리케이션 계층과 SAP 구성 요소의 DBMS 계층 간의 통신 경로에서 네트워크 가상 어플라이언스를 구성하는 것은 지원되지 않습니다.

    통신 경로의 네트워크 가상 어플라이언스는 두 통신 파트너 간의 네트워크 대기 시간을 쉽게 두 배로 늘릴 수 있습니다. 또한 SAP 애플리케이션 계층과 DBMS 계층 간의 중요한 경로에서 처리량을 제한할 수 있습니다. 일부 시나리오에서 네트워크 가상 어플라이언스로 인해 Linux Pacemaker 클러스터가 실패할 수 있습니다.

    SAP 애플리케이션 계층과 DBMS 계층 간의 통신 경로는 직접 경로여야 합니다. ASG 및 NSG 규칙에서 직접 통신 경로를 허용하는 경우에는 ASG 및 NSG 규칙이 제한에 포함되지 않습니다.

    네트워크 가상 어플라이언스를 지원하지 않는 다른 시나리오는 다음과 같습니다.

  • SAP 애플리케이션 계층과 DBMS 계층을 다른 Azure 가상 네트워크로 분리하는 것은 지원되지 않습니다. 다른 Azure 가상 네트워크를 사용하는 대신, 동일한 Azure 가상 네트워크 내의 서브넷을 사용하여 SAP 애플리케이션 계층과 DBMS 계층을 분리하는 것이 좋습니다.

    서로 다른 가상 네트워크에서 두 SAP 시스템 계층을 분리하는 지원되지 않는 시나리오를 설정하는 경우 두 가상 네트워크를 피어해야 합니다.

    피어링된 두 Azure 가상 네트워크 간의 네트워크 트래픽에는 전송 비용이 부과됩니다. 매일 테라바이트급의 대용량 데이터 볼륨이 SAP 애플리케이션 계층과 DBMS 계층 간에 교환됩니다. SAP 애플리케이션 계층 및 DBMS 계층이 두 피어링된 Azure Virtual Network 간에 분리된 경우 상당한 비용이 발생할 수 있습니다.

이름 확인 및 도메인 서비스

DNS를 통해 호스트 이름을 IP 주소로 확인하는 것은 SAP 네트워킹에 중요한 요소인 경우가 많습니다. Azure에서 이름 및 IP 확인을 구성하는 여러 옵션이 있습니다.

엔터프라이즈에는 전체 아키텍처의 일부인 중앙 DNS 솔루션이 있는 경우가 많습니다. 고유한 DNS 서버를 설정하는 대신 기본적으로 Azure에서 이름 확인을 구현하기 위한 몇 가지 옵션은 Azure 가상 네트워크의 리소스에 대한 이름 확인에 설명되어 있습니다.

DNS 서비스와 마찬가지로 SAP VM 또는 서비스에서 Windows Server Active Directory에 액세스할 수 있어야 하는 요구 사항이 있을 수 있습니다.

IP 주소 할당

NIC의 IP 주소는 VM의 NIC가 존재하는 동안 계속 클레임되고 사용됩니다. 규칙은 동적 및 고정 IP 할당 모두에 적용됩니다. VM이 실행 중인지 아니면 종료되는지에 관계없이 true로 유지됩니다. 동적 IP 할당은 NIC가 삭제되거나 서브넷이 변경되거나 할당 방법이 정적으로 변경되는 경우 해제됩니다.

Azure Virtual Network 내의 VM에 고정 IP 주소를 할당할 수 있습니다. IP 주소는 종종 외부 DNS 서버 및 정적 항목에 의존하는 SAP 시스템에 대해 다시 할당됩니다. IP 주소는 VM 및 해당 NIC가 삭제될 때까지 또는 IP 주소가 할당되지 않은 상태로 유지됩니다. 가상 네트워크의 IP 주소 범위를 정의할 때 VM의 전체 수(실행 중인 VM 및 중지된 VM)를 고려해야 합니다.

자세한 내용은 고정 개인 IP 주소가 있는 VM 만들기를 참조하세요.

참고 항목

Azure VM 및 해당 NIC에 대한 고정 및 동적 IP 주소 할당 중에서 결정해야 합니다. VM의 게스트 운영 체제는 VM이 부팅될 때 NIC에 할당된 IP를 가져옵니다. 게스트 운영 체제의 고정 IP 주소를 NIC에 할당해서는 안 됩니다. Azure Backup과 같은 일부 Azure 서비스는 최소한 기본 NIC가 운영 체제 내의 고정 IP 주소가 아닌 DHCP로 설정된다는 사실에 의존합니다. 자세한 내용은 Azure VM 백업 문제 해결을 참조하세요.

SAP 호스트 이름 가상화를 위한 보조 IP 주소

각 Azure VM의 NIC에는 여러 IP 주소가 할당되어 있을 수 있습니다. 보조 IP는 DNS A 레코드 또는 DNS PTR 레코드에 매핑되는 SAP 가상 호스트 이름에 사용할 수 있습니다. 보조 IP 주소는 Azure NIC의 IP 구성에 할당되어야 합니다. 보조 IP는 DHCP를 통해 할당되지 않는 경우가 많으므로 운영 체제 내에서도 보조 IP를 정적으로 구성해야 합니다. 각 보조 IP는 NIC가 바인딩된 동일한 서브넷에 있어야 합니다. VM을 중지하거나 할당 취소하지 않고 Azure NIC에서 보조 IP를 추가하고 제거할 수 있습니다. NIC의 기본 IP를 추가하거나 제거하려면 VM의 할당을 취소해야 합니다.

Azure 부하 분산 장치는 Pacemaker 클러스터를 사용하는 SAP 고가용성 아키텍처에서 사용됩니다. 이 시나리오에서 부하 분산 장치는 SAP 가상 호스트 이름을 사용하도록 설정합니다. 가상 호스트 이름 사용에 대한 일반적인 지침은 SAP Note 962955를 참조하세요.

SAP를 실행하는 VM을 사용하는 Azure Load Balancer

부하 분산 장치는 일반적으로 고가용성 아키텍처에서 활성 및 수동 클러스터 노드 간에 부동 IP 주소를 제공하는 데 사용됩니다. 단일 VM에 대한 부하 분산 장치를 사용하여 SAP 가상 호스트 이름에 대한 가상 IP 주소를 보유할 수도 있습니다. 단일 VM에 부하 분산 장치를 사용하는 것은 NIC에서 보조 IP 주소를 사용하거나 동일한 서브넷에서 여러 NIC를 사용하는 대안입니다.

표준 부하 분산 장치는 기본적으로 아키텍처가 안전하기 때문에 기본 아웃바운드 액세스 경로를 수정합니다. 표준 부하 분산 장치 뒤에 있는 VM은 더 이상 동일한 퍼블릭 엔드포인트에 연결할 수 없습니다. 몇 가지 예는 운영 체제 업데이트 리포지토리의 엔드포인트 또는 Azure 서비스의 퍼블릭 엔드포인트입니다. 아웃바운드 연결을 제공하는 옵션은 Azure 표준 부하 분산 장치를 사용하여 VM에 대한 퍼블릭 엔드포인트 연결을 참조하세요.

팁

기본 부하 분산 장치는 Azure의 SAP 아키텍처와 함께 사용하면 안 됩니다. 기본 부하 분산 장치는 사용 중지되도록 예약됩니다.

VM당 여러 vNIC

기본 vNIC와 동일한 가상 네트워크의 서브넷에 할당된 각 vNIC를 사용하여 Azure VM에 대해 여러 vNIC(가상 네트워크 인터페이스 카드)를 정의할 수 있습니다. 여러 vNIC를 사용할 수 있으므로 필요한 경우 네트워크 트래픽 분리를 설정할 수 있습니다. 예를 들어 클라이언트 트래픽은 기본 vNIC를 통해 라우팅되고 일부 관리자 또는 백 엔드 트래픽은 두 번째 vNIC를 통해 라우팅됩니다. 사용하는 운영 체제 및 이미지에 따라 올바른 라우팅을 위해 운영 체제 내의 NIC에 대한 트래픽 경로를 설정해야 할 수 있습니다.

VM의 유형과 크기는 VM에 할당할 수 있는 vNIC 수를 결정합니다. 기능 및 제한 사항에 대한 자세한 내용은 Azure Portal을 사용하여 VM에 여러 IP 주소 할당을 참조하세요.

VM에 vNIC를 추가해도 사용 가능한 네트워크 대역폭은 증가하지 않습니다. 모든 네트워크 인터페이스는 동일한 대역폭을 공유합니다. VM이 프라이빗 서브넷에 액세스해야 하는 경우에만 여러 NIC를 사용하는 것이 좋습니다. NSG 기능을 사용하고 네트워크 및 서브넷 요구 사항을 간소화하는 디자인 패턴을 사용하는 것이 좋습니다. 디자인은 가능한 한 적은 수의 네트워크 인터페이스를 사용해야 하며 최적으로는 하나만 사용해야 합니다. HANA 내부 네트워크에 보조 vNIC가 필요한 HANA 스케일 아웃은 예외입니다.

Warning

VM에서 여러 vNIC를 사용하는 경우 기본 NIC의 서브넷을 사용하여 사용자 네트워크 트래픽을 처리하는 것이 좋습니다.

가속된 네트워킹

Azure VM 간의 네트워크 대기 시간을 더 줄이려면 SAP 워크로드를 실행하는 모든 VM에서 Azure 가속 네트워킹이 사용하도록 설정되어 있는지 확인하는 것이 좋습니다. 새 VM에 대해 기본적으로 가속화된 네트워킹이 사용하도록 설정되어 있지만 배포 검사 목록에 따라 상태를 확인해야 합니다. 가속화된 네트워킹의 이점은 네트워킹 성능 및 대기 시간을 크게 향상시켰습니다. SAP 워크로드, 특히 지원되는 모든 VM의 SAP 애플리케이션 계층 및 SAP DBMS 계층에 대해 Azure VM을 배포할 때 이 도구를 사용합니다. 연결된 설명서에는 운영 체제 버전 및 VM 인스턴스에 대한 지원 종속성이 포함되어 있습니다.

온-프레미스 연결

Azure의 SAP 배포에서는 온-프레미스 연결을 사용하도록 설정하기 위해 중앙 엔터프라이즈 차원의 네트워크 아키텍처 및 통신 허브가 마련되어 있다고 가정합니다. 온-프레미스 네트워크 연결은 사용자와 애플리케이션이 Azure의 SAP 지형에 액세스하여 중앙 DNS, 도메인, 보안 및 패치 관리 인프라와 같은 다른 중앙 조직 서비스에 액세스할 수 있도록 하는 데 필수적입니다.

Azure 배포에서 SAP에 대한 온-프레미스 연결을 제공하는 많은 옵션이 있습니다. 네트워킹 배포는 허브-스포크 네트워크 토폴로지 또는 허브-스포크 토폴로지의 확장인 글로벌 가상 WAN입니다.

온-프레미스 SAP 배포의 경우 Azure ExpressRoute를 통해 프라이빗 연결을 사용하는 것이 좋습니다. 더 작은 SAP 워크로드, 원격 지역 또는 더 작은 사무실의 경우 VPN 온-프레미스 연결을 사용할 수 있습니다. VPN을 통한 ExpressRoute 사이트 간 연결을 장애 조치(failover) 경로로 사용하는 것은 두 서비스의 가능한 조합입니다.

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

SAP 환경을 사용하려면 운영 체제 리포지토리 업데이트를 받든, 공용 엔드포인트에서 SAP SaaS 애플리케이션에 대한 연결을 설정하든, 퍼블릭 엔드포인트를 통해 Azure 서비스에 액세스하든 인터넷에 연결해야 합니다. 마찬가지로, SAP 환경에서 제공하는 서비스에 액세스하는 인터넷 사용자가 있는 SAP Fiori 애플리케이션에 대한 클라이언트 액세스를 제공해야 할 수 있습니다. SAP 네트워크 아키텍처를 사용하려면 인터넷 및 들어오는 요청에 대한 경로를 계획해야 합니다.

NSG 규칙을 사용하고, 알려진 서비스에 대해 네트워크 서비스 태그를 사용하고, 방화벽 또는 기타 네트워크 가상 어플라이언스에 대한 라우팅 및 IP 주소를 설정하여 가상 네트워크를 보호합니다. 이러한 모든 작업 또는 고려 사항은 아키텍처의 일부입니다. 프라이빗 네트워크의 리소스는 네트워크 계층 4 및 계층 7 방화벽으로 보호되어야 합니다.

인터넷과의 통신 경로는 모범 사례 아키텍처의 초점입니다.

SAP 워크로드용 Azure VM

일부 Azure VM 제품군은 SAP 워크로드 및 SAP HANA 워크로드에 특히 적합합니다. SAP 워크로드를 지원하기에 알맞은 VM 유형과 기능을 찾는 방법은 Azure 배포에 대해 지원되는 SAP 소프트웨어에 설명되어 있습니다. 또한 SAP Note 1928533는 (해당하는 경우) SAPS(애플리케이션 성능 표준) 벤치마크 및 제한 사항에 의해 측정된 모든 인증된 Azure VM 및 해당 성능 기능을 나열합니다. SAP 워크로드에 대해 인증된 VM 유형은 CP와 메모리 리소스에 대해 오버프로비전을 사용하지 않습니다.

지원되는 VM 유형 선택을 보는 것 외에도 지역별 이용 가능한 제품을 참고하여 해당 VM 유형이 특정 지역에서 제공되는지 확인해야 합니다. 적어도 중요한 것은 VM에 대한 다음 기능이 시나리오에 적합한지 여부를 결정하는 것입니다.

  • CPU 및 메모리 리소스
  • IOPS(초당 입출력 작업) 대역폭
  • 네트워크 기능
  • 연결할 수 있는 디스크 수
  • 특정 Azure 스토리지 유형을 사용하는 기능

특정 FM 제품군 및 유형에 대한 이 정보를 얻으려면 Azure의 가상 머신 크기를 참조하세요.

Azure VM에 대한 가격 책정 모델

VM 가격 책정 모델의 경우 사용하려는 옵션을 선택할 수 있습니다.

  • 종량제 가격 책정 모델
  • 1년 예약 또는 저축 계획
  • 3년 예약 또는 저축 계획
  • 스폿 가격 책정 모델

다른 Azure 서비스, 운영 체제 및 지역에 대한 VM 가격 책정에 대한 자세한 내용은 가상 머신 가격 책정을 참조하세요.

1년 및 3년 절감 플랜 및 예약 인스턴스의 가격 책정 및 유연성에 대해 알아보려면 다음 문서를 참조하세요.

스폿 가격 책정에 대한 자세한 내용은 Azure Spot Virtual Machines를 참조하세요.

동일한 VM 유형에 대한 가격은 Azure 지역마다 다를 수 있습니다. 일부 고객은 저렴한 Azure 지역에 배포하는 이점을 누릴 수 있으므로 계획할 때 지역별 가격 책정에 대한 정보가 유용할 수 있습니다.

Azure는 전용 호스트를 사용하는 옵션도 제공합니다. 전용 호스트를 사용하면 Azure 서비스에 대한 패치 주기를 더 많이 제어할 수 있습니다. 고유한 일정 및 주기를 지원하도록 패치를 예약할 수 있습니다. 이 제품은 워크로드의 정상적인 주기를 따르지 않는 워크로드가 있는 고객을 위해 특별히 제공됩니다. 자세한 내용은 Azure 전용 호스트를 참조하세요.

AZURE 전용 호스트 사용은 SAP 워크로드에 대해 지원됩니다. 인프라 패치 및 유지 관리 계획을 보다 세세하게 제어하려는 여러 SAP 고객은 Azure 전용 호스트를 사용합니다. Microsoft가 VM을 호스팅하는 Azure 인프라를 관리하고 패치하는 방법에 대한 자세한 정보는 Azure에서 가상 머신 유지관리를 참조하세요.

VM용 운영 체제

SAP 시스템을 설치하거나 마이그레이션하기 위해 Azure의 SAP 환경용 새 VM을 배포하는 경우 워크로드에 적합한 운영 시스템을 선택하는 것이 중요합니다. Azure는 Linux 및 Windows용 다양한 운영 체제 이미지와 SAP 시스템에 적합한 다양한 옵션을 제공합니다. 온-프레미스 환경에서 사용자 지정 이미지를 만들거나 업로드하거나 이미지 갤러리에서 사용하거나 일반화할 수도 있습니다.

사용할 수 있는 옵션에 대한 세부 정보 및 정보는 다음과 같습니다.

필요한 경우 운영 체제 업데이트 인프라 및 SAP 워크로드에 대한 종속성을 계획합니다. 리포지토리 스테이징 환경을 사용하여 업데이트 기간 동안 동일한 버전의 패치 및 업데이트를 사용하여 SAP 환경의 모든 계층(샌드박스, 개발, 사전 프로덕션 및 프로덕션)을 동기화 상태로 유지하는 것이 좋습니다.

1세대 및 2세대 VM

Azure에서 VM을 1세대 또는 2세대로 배포할 수 있습니다. Azure에서 2세대 VM에 대한 지원은 2세대로 배포할 수 있는 Azure VM 제품군을 나열합니다. 또한 이 문서에서는 Azure의 1세대 VM과 2세대 VM 간의 기능적 차이점을 나열합니다.

VM을 배포할 때 선택한 운영 체제 이미지는 VM이 1세대 또는 2세대 VM인지를 결정합니다. Azure에서 사용할 수 있는 SAP용 모든 운영 체제 이미지의 최신 버전(Red Hat Enterprise Linux, SuSE Enterprise Linux 및 Windows 또는 Oracle Enterprise Linux)은 1세대와 2세대 모두에서 사용할 수 있습니다. 올바른 VM 생성을 배포하려면 이미지 설명에 따라 이미지를 신중하게 선택하는 것이 중요합니다. 마찬가지로 사용자 지정 운영 체제 이미지를 1세대 또는 2세대로 만들 수 있으며 VM이 배포되면 VM의 세대에 영향을 줍니다.

참고 항목

VM 크기에 관계없이 Azure의 모든 SAP 배포에서 2세대 VM을 사용하는 것이 좋습니다. SAP용 모든 최신 Azure VM은 2세대를 지원하거나 2세대로만 제한됩니다. 일부 VM 제품군은 현재 2세대 VM만 지원합니다. 곧 사용할 수 있는 일부 VM 제품군은 2세대만 지원할 수 있습니다.

선택한 운영 체제 이미지를 기반으로 VM이 1세대인지 아니면 2세대인지 확인할 수 있습니다. 기존 VM을 한 세대에서 다른 세대로 변경할 수 없습니다.

Azure에서는 배포된 VM을 1세대에서 2세대로 변경할 수 없습니다. VM 생성을 변경하려면 원하는 세대인 새 VM을 배포하고 새 세대의 VM에 소프트웨어를 다시 설치해야 합니다. 이 변경 내용은 VM의 기본 VHD 이미지에만 영향을 미치며 데이터 디스크 또는 연결된 NFS(네트워크 파일 시스템) 또는 SMB(서버 메시지 블록) 공유에 영향을 주지 않습니다. 원래 1세대 VM에 할당된 데이터 디스크, NFS 공유 또는 SMB 공유를 새 2세대 VM에 연결할 수 있습니다.

Mv2 시리즈와 같은 일부 VM 제품군은 2세대만 지원합니다. 향후 새 VM 제품군에서도 동일한 요구 사항이 적용될 수 있습니다. 이 시나리오에서는 기존 1세대 VM의 크기를 조정하여 새 VM 제품군을 사용할 수 없습니다. Azure 플랫폼의 2세대 요구 사항 외에도 SAP 구성 요소에는 VM 생성과 관련된 요구 사항이 있을 수 있습니다. 선택한 VM 제품군에 대한 2세대 요구 사항에 대해 알아보려면 SAP Note 1928533을 참조하세요.

Azure VM에 대한 성능 제한

퍼블릭 클라우드인 Azure는 고객 기반 전체에서 보안 방식으로 인프라를 공유하는 데 의존합니다. 크기 조정 및 용량을 사용하도록 설정하기 위해 각 리소스 및 서비스에 대한 성능 제한이 정의됩니다. Azure 인프라의 컴퓨팅 쪽에서 각 VM 크기에 대해 정의된 제한을 고려하는 것이 중요합니다.

각 VM에는 디스크 및 네트워크 처리량, 연결할 수 있는 디스크 수, 자체 처리량 및 IOPS 제한이 있는 로컬 임시 스토리지가 있는지 여부, 메모리 크기 및 사용 가능한 vCPU 수에 대해 서로 다른 할당량이 있습니다.

참고 항목

Azure의 SAP 솔루션에 대한 VM 크기에 대한 결정을 내릴 때 각 VM 크기에 대한 성능 제한을 고려해야 합니다. 설명서에 설명된 할당량은 이론적 최대 달성 가능 값을 나타냅니다. 디스크당 IOPS의 성능 제한은 작은 입력/출력(I/O) 값(예: 8KB)으로 달성할 수 있지만 큰 I/O 값(예: 1MB)으로는 달성되지 않을 수 있습니다.

VM과 마찬가지로 SAP 워크로드의 각 스토리지 유형 및 다른 모든 Azure 서비스에 대해 동일한 성능 제한이 존재합니다.

SAP 배포에서 사용할 VM을 계획하고 선택하는 경우 다음 요소를 고려합니다.

  • 메모리 및 CPU 요구 사항부터 시작합니다. CPU 전원에 대한 SAPS 요구 사항을 DBMS 부분 및 SAP 애플리케이션 파트로 분리합니다. 기존 시스템의 경우 사용 중인 하드웨어 관련된 SAPS를 기존 SAP 표준 애플리케이션 벤치마크를 기준으로 결정하거나 예측할 수 있습니다. 새로 배포된 SAP 시스템의 경우 시스템에 대한 SAPS 요구 사항을 결정하는 크기 조정 연습을 완료합니다.

  • 기존 시스템의 경우 DBMS 서버의 I/O 처리량 및 IOPS를 측정해야 합니다. 새 시스템의 경우는 새 시스템에 대한 크기 조정 연습 과정을 진행하면서 DBMS에 대한 I/O 요구 사항을 일반적으로 알 수 있습니다. 확실하지 않은 경우 결국 개념 증명을 수행해야 합니다.

  • DBMS 서버의 SAPS 요구 사항과 여러 다른 VM 형식의 Azure가 제공할 수 있는 SAPS를 비교합니다. 다른 Azure VM 형식의 SAPS에 대한 관련 정보는 SAP 정보 1928533에 나와 있습니다. 데이터베이스 계층이 대부분의 배포에서는 확장되지 않는 SAP NetWeaver 시스템의 계층이므로 먼저 DBMS VM을 중점적으로 설명합니다. 반면 SAP 애플리케이션 계층은 확장될 수 있습니다. 개별 DBMS 가이드에서는 권장되는 스토리지 구성에 대해 설명합니다.

  • 다음 사항에 대한 결과를 요약합니다.

    • 사용할 Azure VM의 수.
    • 각 SAP 계층에 대한 개별 VM 제품군 및 VM SKU: DBMS, (A)SCS 및 애플리케이션 서버.
    • I/O 처리량 측정값 또는 계산된 스토리지 용량 요구 사항.

HANA 대규모 인스턴스 서비스

Azure는 Azure의 SAP HANA(대규모 인스턴스)라는 전용 제품에서 대규모 HANA 데이터베이스를 확장 또는 스케일 아웃하는 컴퓨팅 기능을 제공합니다. 이 제품은 Azure에서 사용할 수 있는 VM을 확장합니다.

참고 항목

HANA 대규모 인스턴스 서비스는 종료 모드이며 신규 고객을 받지 않습니다. 기존 HANA 대규모 인스턴스 고객을 위한 단위 제공은 여전히 가능합니다.

Azure의 SAP용 스토리지

Azure VM은 지속성을 위해 다양한 스토리지 옵션을 사용합니다. 간단히 말하면 VM을 영구 스토리지 유형과 임시 또는 비영구 스토리지 유형으로 나눌 수 있습니다.

SAP 워크로드 및 특정 SAP 구성 요소에 대한 여러 스토리지 옵션 중에서 선택할 수 있습니다. 자세한 내용은 SAP 워크로드용 Azure Storage를 참조하세요. 이 문서에서는 운영 체제, 애플리케이션 이진 파일, 구성 파일, 데이터베이스 데이터, 로그 및 추적 파일, 디스크에 저장되거나 파일 공유에 액세스된 다른 애플리케이션과의 파일 인터페이스 등 SAP의 모든 부분에 대한 스토리지 아키텍처를 다룹니다.

VM의 임시 디스크

SAP용 대부분의 Azure VM은 관리 디스크가 아닌 임시 디스크를 제공합니다. 소모성 데이터에 한해 임시 디스크를 사용합니다. 예기치 않은 유지 관리 이벤트 중 또는 VM을 다시 배포하는 동안 임시 디스크의 데이터가 손실될 수 있습니다. 임시 디스크의 성능 특성 때문에 운영 체제의 스왑/페이지 파일에 적합합니다.

임시 디스크에 애플리케이션 또는 존재하지 않는 운영 체제 데이터를 저장해서는 안 됩니다. Windows 환경에서 임시 드라이브는 일반적으로 드라이브 D로 액세스됩니다. Linux 시스템에서 탑재 지점은 /dev/sdb device, /mnt 또는 /mnt/resource인 경우가 많습니다.

일부 VM은 임시 드라이브를 제공하지 않습니다. SAP에 이러한 VM 크기를 사용하려는 경우 운영 체제 디스크의 크기를 늘려야 할 수 있습니다. 자세한 내용은 SAP Note 1928533을 참조하세요. 임시 디스크가 있는 VM의 경우 Azure의 가상 머신 크기에서 각 VM 시리즈에 대한 임시 디스크 크기 및 IOPS 및 처리량 제한에 대한 정보를 가져옵니다.

임시 디스크가 있는 VM 시리즈와 임시 디스크가 없는 VM 시리즈 간에는 직접 크기를 조정할 수 없습니다. 현재 이러한 두 VM 제품군 간의 크기 조정이 실패합니다. 해결 방법은 운영 체제 디스크 스냅샷을 사용하여 새 크기에 임시 디스크가 없는 VM을 다시 만드는 것입니다. 다른 모든 데이터 디스크 및 네트워크 인터페이스를 유지합니다. 로컬 임시 디스크가 있는 VM 크기를 그렇지 않은 VM 크기로 조정하는 방법을 알아봅니다.

SAP용 네트워크 공유 및 볼륨

SAP 시스템에는 일반적으로 하나 이상의 네트워크 파일 공유가 필요합니다. 파일 공유는 일반적으로 다음 옵션 중 하나입니다.

  • SAP 전송 디렉터리(/usr/sap/trans 또는 TRANSDIR).
  • 여러 애플리케이션 서버를 배포하기 위한 SAP 볼륨 또는 공유 sapmnt 또는 saploc 볼륨.
  • SAP(A)SCS, SAP ERS 또는 데이터베이스(/hana/shared)에 대한 고가용성 아키텍처 볼륨.
  • 파일 가져오기 및 내보내기용 타사 애플리케이션을 실행하는 파일 인터페이스.

이러한 시나리오에서는 Azure Files 또는 Azure NetApp Files와 같은 Azure 서비스를 사용하는 것이 좋습니다. 선택한 지역에서 이러한 서비스를 사용할 수 없거나 솔루션 아키텍처에 사용할 수 없는 경우 자체 관리형 VM 기반 애플리케이션 또는 타사 서비스에서 NFS 또는 SMB 파일 공유를 제공하는 것이 대안입니다. Azure의 SAP 시스템에서 스토리지 계층에 타사 서비스를 사용하는 경우 SAP 지원에 대한 제한 사항에 대한 SAP Note 2015553을 참조하세요.

네트워크 공유의 중요한 특성과 디자인(고가용성) 또는 프로세스(파일 인터페이스의 경우)의 단일 실패 지점인 경우가 많기 때문에 자체 가용성, SLA 및 복원력을 위해 각 Azure 네이티브 서비스를 사용하는 것이 좋습니다. 계획 단계에서는 다음 요소를 고려해야 합니다.

  • SAP SID(시스템 ID), 지형별 및 지역별로 사용할 공유를 포함하여 NFS 또는 SMB 공유 디자인
  • 프라이빗 엔드포인트 또는 Azure NetApp Files와 같은 서비스에 대한 전용 서브넷에 대한 IP 요구 사항을 포함하여 서브넷 크기 조정
  • SAP 시스템 및 연결된 애플리케이션에 대한 네트워크 라우팅.
  • Azure Files에 대한 퍼블릭 또는 프라이빗 엔드포인트 사용.

고가용성 시나리오에서 NFS 또는 SMB 공유를 사용하는 방법 및 요구 사항에 대한 자세한 내용은 고가용성을 참조하세요.

참고 항목

네트워크 공유에 Azure Files를 사용하는 경우 프라이빗 엔드포인트를 사용하는 것이 좋습니다. 영역 오류가 발생할 가능성이 낮으면 NFS 클라이언트가 자동으로 정상 영역으로 리디렉션됩니다. VM에서 NFS 또는 SMB 공유를 다시 탑재할 필요가 없습니다.

SAP 환경을 위한 보안

Azure에서 SAP 워크로드를 보호하려면 보안의 여러 측면을 계획해야 합니다.

  • 네트워크 세분화 및 각 서브넷 및 네트워크 인터페이스의 보안.
  • SAP 환경 내의 각 계층에 대한 암호화.
  • 최종 사용자 및 관리 액세스 및 Single Sign-On 서비스에 대한 ID 솔루션.
  • 위협 및 작업 모니터링.

이 챕터의 항목은 사용 가능한 모든 서비스, 옵션 및 대안의 전체 목록이 아닙니다. Azure의 모든 SAP 배포에 대해 고려해야 하는 몇 가지 모범 사례를 나열합니다. 엔터프라이즈 또는 워크로드 요구 사항에 따라 다룰 다른 측면이 있습니다. 보안 디자인에 대한 자세한 내용은 일반 Azure 지침에 대한 다음 리소스를 참조하세요.

보안 그룹을 사용하여 가상 네트워크 보호

Azure에서 SAP 환경을 계획하려면 SAP 워크로드 전용 가상 네트워크 및 서브넷을 사용하여 어느 정도의 네트워크 분할을 포함해야 합니다. 서브넷 정의에 대한 모범 사례는 네트워킹 및 다른 Azure 아키텍처 가이드에 설명되어 있습니다. NSG 내에서 ASG와 함께 NSG를 사용하여 인바운드 및 아웃바운드 연결을 허용하는 것이 좋습니다. ASG를 디자인할 때 VM의 각 NIC를 여러 ASG와 연결할 수 있으므로 다른 그룹을 만들 수 있습니다. 예를 들어 환경 전체의 모든 데이터베이스 서버를 포함하는 DBMS VM용 ASG를 만듭니다. 단일 SAP SID의 모든 VM(애플리케이션 및 DBMS)에 대해 다른 ASG를 만듭니다. 이렇게 하면 전체 데이터베이스 ASG에 대해 하나의 NSG 규칙을 정의하고 SID별 ASG에 대해서만 더 구체적인 규칙을 정의할 수 있습니다.

NSG는 NSG에 대해 정의한 규칙으로 성능을 제한하지 않습니다. 트래픽 흐름을 모니터링하기 위해 선택적으로 의심스러운 네트워크 활동을 모니터링하고 작동하기 위해 선택한 SIEM(정보 이벤트 관리) 또는 IDS(침입 감지 시스템)에서 평가한 로그를 사용하여 NSG 흐름 로깅을 활성화할 수 있습니다.

팁

서브넷 수준에서만 NSG를 활성화합니다. 서브넷 수준과 NIC 수준 모두에서 NSG를 활성화할 수 있지만, 네트워크 트래픽 제한을 분석할 때 두 가지 모두에 대한 정품 인증은 문제 해결에 방해가 되는 경우가 많습니다. 예외적인 상황과 필요한 경우에만 NIC 수준에서 NSG를 사용합니다.

서비스의 프라이빗 엔드포인트

대부분의 Azure PaaS 서비스는 기본적으로 퍼블릭 엔드포인트를 통해 액세스됩니다. 통신 엔드포인트는 Azure 백 엔드 네트워크에 있지만 엔드포인트는 공용 인터넷에 노출됩니다. 프라이빗 엔드포인트는 사용자 고유의 프라이빗 가상 네트워크 내의 네트워크 인터페이스입니다. Azure Private Link를 통해 프라이빗 엔드포인트는 서비스를 가상 네트워크에 투영합니다. 선택한 PaaS 서비스는 네트워크 내의 IP를 통해 비공개로 액세스됩니다. 구성에 따라 프라이빗 엔드포인트를 통해서만 통신하도록 서비스를 설정할 수 있습니다.

프라이빗 엔드포인트를 사용하면 데이터 유출에 대한 보호가 강화되며, 온-프레미스 및 피어링된 네트워크에서의 액세스가 간소화되는 경우가 많습니다. 대부분의 경우 공용 엔드포인트에 필요한 방화벽 포트를 여는 네트워크 라우팅 및 프로세스가 간소화됩니다. 리소스는 프라이빗 엔드포인트에서 액세스하기 때문에 이미 네트워크 내에 있습니다.

프라이빗 엔드포인트를 사용하는 옵션을 제공하는 Azure 서비스를 알아보려면 Private Link 사용 가능한 서비스를 참조하세요. Azure Files를 사용하는 NFS 또는 SMB의 경우 SAP 워크로드에 항상 프라이빗 엔드포인트를 사용하는 것이 좋습니다. 서비스를 사용하여 발생하는 요금에 대해 알아보려면 프라이빗 엔드포인트 가격을 참조하세요. 일부 Azure 서비스에는 필요에 따라 서비스에 비용이 포함될 수 있습니다. 이 정보는 서비스의 가격 책정 정보에 포함됩니다.

암호화

회사 정책에 따라 SAP 워크로드에 Azure의 기본 옵션 이상의 암호화가 필요할 수 있습니다.

인프라 리소스에 대한 암호화

기본적으로 Azure의 관리 디스크 및 Blob Storage는 PMK(플랫폼 관리형 키)로 암호화됩니다. 또한 관리 디스크 및 Blob Storage에 대한 BYOK(Bring Your Own Key) 암호화는 Azure의 SAP 워크로드에 대해 지원됩니다. 관리 디스크 암호화의 경우 회사 보안 요구 사항에 따라 다양한 옵션 중에서 선택할 수 있습니다. Azure 암호화 옵션은 다음과 같습니다.

  • SSE(스토리지 쪽 암호화) PMK(SSE-PMK)
  • SSE 고객 관리형 키(SSE-CMK)
  • 미사용 이중 암호화
  • 호스트 기반 암호화

Azure Disk Encryption에 대한 설명을 비롯한 자세한 내용은 Azure 암호화 옵션 비교를 참조하세요.

참고 항목

현재 잠재적인 성능 제한으로 인해 Linux로 실행할 때 M 시리즈 VM 제품군에 있는 VM에서 호스트 기반 암호화를 사용하지 마세요. 관리 디스크에 대한 SSE-CMK 암호화 사용은 이 제한 사항의 영향을 받지 않습니다.

Linux 시스템에서 SAP 배포의 경우 Azure Disk Encryption을 사용하지 마세요. Azure Disk Encryption은 Azure Key Vault의 CMK를 사용하여 SAP VM 내에서 실행되는 암호화를 수반합니다. Linux의 경우 Azure Disk Encryption은 SAP 워크로드에 사용되는 운영 체제 이미지를 지원하지 않습니다. Azure Disk Encryption은 SAP 워크로드가 있는 Windows 시스템에서 사용할 수 있지만 Azure Disk Encryption을 데이터베이스 네이티브 암호화와 결합하지 마세요. Azure Disk Encryption 대신 데이터베이스 네이티브 암호화를 사용하는 것이 좋습니다. 자세한 내용은 다음 섹션을 참조하세요.

관리 디스크 암호화와 마찬가지로 미사용 Azure Files 암호화(SMB 및 NFS)는 PMK 또는 CMK에서 사용할 수 있습니다.

SMB 네트워크 공유의 경우 구성이 전송 중 암호화 지원에 영향을 주므로 Azure Files 및 운영 체제 종속성을 SMB 버전과 함께 신중하게 검토합니다.

Important

고객 관리형 암호화를 사용하는 경우 암호화 키를 저장하고 보호하는 신중한 계획의 중요성은 과장될 수 없습니다. 암호화 키가 없으면 디스크와 같은 암호화된 리소스에 액세스할 수 없으며 데이터 손실이 발생할 수 있습니다. 권한 있는 사용자 또는 서비스에 대해서만 키와 키에 대한 액세스를 보호하는 것이 좋습니다.

SAP 구성 요소에 대한 암호화

SAP 수준의 암호화는 다음 두 계층으로 구분할 수 있습니다.

  • DBMS 암호화
  • 전송 암호화

DBMS 암호화의 경우 SAP NetWeaver 또는 SAP S/4HANA 배포에 대해 지원되는 각 데이터베이스는 네이티브 암호화를 지원합니다. 투명한 데이터베이스 암호화는 Azure에 있는 인프라 암호화와 완전히 독립적입니다. SSE 및 데이터베이스 암호화를 동시에 사용할 수 있습니다. 암호화를 사용하는 경우 암호화 키의 위치, 스토리지 및 보관이 매우 중요합니다. 암호화 키가 손실되면 데이터베이스를 시작하거나 복구할 수 없으므로 데이터가 손실됩니다.

일부 데이터베이스에는 데이터베이스 암호화 방법이 없거나 전용 설정이 필요하지 않을 수 있습니다. 다른 데이터베이스의 경우 데이터베이스 암호화가 활성화될 때 DBMS 백업이 암시적으로 암호화될 수 있습니다. 투명한 데이터베이스 암호화를 사용하도록 설정하고 사용하는 방법을 알아보려면 다음 SAP 설명서를 참조하세요.

소프트웨어 암호화를 사용, 사용 또는 해결하는 방법에 대한 지원은 SAP 또는 DBMS 공급업체에 문의하세요.

Important

암호화 키를 저장하고 보호하기 위해 신중한 계획을 세우는 것이 얼마나 중요한지 과장할 수 없습니다. 암호화 키가 없으면 데이터베이스 또는 SAP 소프트웨어에 액세스할 수 없으며 데이터가 손실될 수 있습니다. 키를 보호하는 방법을 신중하게 고려합니다. 권한 있는 사용자 또는 서비스에서만 키에 대한 액세스를 허용합니다.

전송 또는 통신 암호화는 SAP 엔진과 DBMS 간의 SQL Server 연결에 적용할 수 있습니다. 마찬가지로 SAP 프레젠테이션 계층(SAPGui 보안 네트워크 연결 또는 SNC) 또는 웹 프런트 엔드에 대한 HTTPS 연결에서 연결을 암호화할 수 있습니다. 전송 중인 암호화를 사용하도록 설정하고 관리하려면 애플리케이션 공급업체의 설명서를 참조하세요.

위협 모니터링 및 경고

위협 모니터링 및 경고 솔루션을 배포하고 사용하려면 먼저 조직의 아키텍처를 사용합니다. Azure 서비스는 전체 SAP 배포 계획에 통합할 수 있는 위협 방지 및 보안 보기를 제공합니다. 클라우드용 Microsoft Defender는 위협 방지 요구 사항을 해결합니다. Defender for Cloud는 일반적으로 SAP 구성 요소뿐만 아니라 전체 Azure 배포에 대한 전체 거버넌스 모델의 일부입니다.

SIEM(보안 정보 이벤트 관리) 및 SOAR(보안 오케스트레이션 자동화 응답) 솔루션에 대한 자세한 내용은 SAP용 Microsoft Sentinel 솔루션 통합을 참조하세요.

SAP VM 내의 보안 소프트웨어

Linux용 SAP Note 2808515 및 Windows용 SAP Note 106267에서는 SAP 서버에서 바이러스 스캐너 또는 보안 소프트웨어를 사용할 때의 요구 사항 및 모범 사례를 설명합니다. Azure에서 SAP 구성 요소를 배포할 때 SAP 권장 사항을 따르는 것이 좋습니다.

고가용성

Azure의 SAP 고가용성에는 다음 두 가지 구성 요소가 있습니다.

  • Azure 인프라 고가용성: Azure 컴퓨팅(VM), 네트워크 및 스토리지 서비스의 고가용성 및 SAP 애플리케이션 가용성을 높일 수 있는 방법.

  • SAP 애플리케이션 고가용성: 서비스 복구를 사용하여 Azure 인프라 고가용성을 결합하는 방법. SAP 소프트웨어 구성 요소에서 고가용성을 사용하는 예제:

    • SAP(A)SCS 및 SAP ERS 인스턴스
    • 데이터베이스 서버

Azure의 SAP 고가용성에 대한 자세한 내용은 다음 문서를 참조하세요.

Linux의 Pacemaker 및 Windows Server 장애 조치(failover) 클러스터링이 Azure에서 Microsoft에서 직접 지원하는 SAP 워크로드에 대한 유일한 고가용성 프레임워크입니다. 다른 고가용성 프레임워크는 Microsoft에서 지원되지 않으며 공급업체의 디자인, 구현 세부 정보 및 운영 지원이 필요합니다. 자세한 내용은 Azure에서 SAP에 대해 지원되는 시나리오를 참조하세요.

재해 복구

종종 SAP 애플리케이션은 기업에서 가장 중요 비즈니스용 프로세스 중 하나입니다. 예기치 않은 중단 후 다시 작동해야 하는 중요도와 시간에 따라 BCDR(비즈니스 연속성 및 재해 복구) 시나리오를 신중하게 계획해야 합니다.

이 요구 사항을 해결하는 방법을 알아보려면 SAP 워크로드에 대한 재해 복구 개요 및 인프라 지침을 참조하세요.

Backup

BCDR 전략의 일환으로 SAP 워크로드에 대한 백업은 계획된 배포의 필수적인 부분이어야 합니다. 백업 솔루션은 VM, 운영 체제, SAP 애플리케이션 계층, DBMS 계층 및 공유 스토리지 솔루션과 같은 SAP 솔루션 스택의 모든 계층을 포함해야 합니다. SAP 워크로드에서 사용되는 Azure 서비스 및 암호화 및 액세스 키와 같은 기타 중요한 리소스에 대한 백업도 백업 및 BCDR 디자인의 일부여야 합니다.

Azure Backup은 백업을 위한 PaaS 솔루션을 제공합니다.

  • VM용 Azure Backup을 통해 VM 구성, 운영 체제 및 SAP 애플리케이션 계층(관리 디스크의 데이터 크기 조정). 지원 매트릭스를 검토하여 아키텍처에서 이 솔루션을 사용할 수 있는지 확인합니다.
  • SQL Server 및 SAP HANA 데이터베이스 데이터 및 로그 백업. 여기에는 HANA 시스템 복제 또는 SQL Always On과 같은 데이터베이스 복제 기술 지원과 쌍을 이루는 지역에 대한 지역 간 지원이 포함됩니다.
  • Azure Files를 통해 파일 공유 백업 NFS 또는 SMB 및 기타 구성 세부 정보에 대한 지원을 확인합니다.

또는 Azure NetApp Files를 배포하는 경우 예약된 백업과 SAP HANA 및 Oracle DBMS 통합을 포함하여 볼륨 수준에서 백업 옵션을 사용할 수 있습니다.

Azure Backup 솔루션은 악의적이거나 실수로 삭제되는 것을 방지하고 데이터 손실을 방지하기 위한 일시 삭제 옵션을 제공합니다. 일시 삭제는 Azure Files를 사용하여 배포하는 파일 공유에도 사용할 수 있습니다.

직접 만들고 관리하는 솔루션이나 타사 소프트웨어를 사용하는 경우 백업 옵션을 사용할 수 있습니다. 옵션은 Blob 데이터에 변경이 불가능한 스토리지를 사용하는 것을 포함하여 Azure Storage에서 서비스를 사용하는 것입니다. 이 자체 관리형 옵션은 현재 SAP ASE 또는 IBM Db2와 같은 일부 데이터베이스에 대한 DBMS 백업 옵션으로 필요합니다.

Azure 모범 사례의 권장 사항을 사용하여 랜섬웨어 공격으로부터 보호하고 유효성을 검사합니다.

팁

백업 전략에 배포 자동화 보호, Azure 리소스에 대한 암호화 키 및 사용되는 경우 투명한 데이터베이스 암호화가 포함되는지 확인합니다.

지역 간 백업

지역 간 백업 요구 사항의 경우 솔루션에서 제공하는 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 BCDR 디자인 및 요구 사항과 일치하는지 여부를 결정합니다.

Azure로 SAP 마이그레이션

다양한 SAP 제품, 버전 종속성, 사용 가능한 네이티브 운영 체제 및 DBMS 기술에 대한 모든 마이그레이션 방법 및 옵션을 설명할 수는 없습니다. 조직 및 서비스 공급자 측의 담당자를 위한 프로젝트 팀은 Azure로의 원활한 SAP 마이그레이션을 위한 몇 가지 기술을 고려해야 합니다.

  • 마이그레이션 중에 성능 테스트. SAP 마이그레이션 계획의 중요한 부분은 기술 성능 테스트입니다. 마이그레이션 팀은 주요 직원이 연결된 인터페이스 및 애플리케이션을 포함하여 마이그레이션된 SAP 시스템의 애플리케이션 및 기술 테스트를 실행할 수 있는 충분한 시간과 가용성을 허용해야 합니다. 성공적인 SAP 마이그레이션의 경우 테스트 환경에서 마이그레이션 후 런타임과 주요 비즈니스 프로세스의 정확도를 비교하는 것이 중요합니다. 프로덕션 환경을 마이그레이션하기 전에 이 정보를 사용하여 프로세스를 최적화합니다.

  • SAP 마이그레이션에 Azure 서비스 사용. 일부 VM 기반 워크로드는 Azure Migrate 또는 Azure Site Recovery와 같은 서비스 또는 타사 도구를 사용하여 Azure로 변경되지 않고 마이그레이션됩니다. 운영 체제 버전과 운영 체제가 실행하는 SAP 워크로드가 서비스에서 지원되는지 부지런히 확인합니다.

    서비스에서 데이터베이스 일관성을 보장할 수 없으므로 데이터베이스 워크로드가 의도적으로 지원되지 않는 경우가 많습니다. 마이그레이션 서비스에서 DBMS 유형을 지원하는 경우 데이터베이스 변경 또는 변동률이 너무 높은 경우가 많습니다. 대부분의 사용 중인 SAP 시스템은 마이그레이션 도구에서 허용하는 변경률을 충족하지 않습니다. 프로덕션 마이그레이션 전까지는 문제가 표시되지 않거나 검색되지 않을 수 있습니다. 대부분의 경우 일부 Azure 서비스는 SAP 시스템을 마이그레이션하는 데 적합하지 않습니다. Azure Site Recovery 및 Azure Migrate에는 대규모 SAP 마이그레이션에 대한 유효성 검사가 없습니다. 입증된 SAP 마이그레이션 방법론은 DBMS 복제 또는 SAP 마이그레이션 도구를 사용하는 것입니다.

    기본 VM 마이그레이션 대신 Azure에서 배포하는 것이 온-프레미스 마이그레이션보다 더 바람직하고 쉽게 수행할 수 있습니다. Azure Center for SAP 솔루션 및 Azure 배포 자동화 프레임워크와 같은 자동화된 배포 프레임워크를 사용하면 자동화된 작업을 신속하게 실행할 수 있습니다. HANA 시스템 복제, DBMS 백업 및 복원 또는 SAP 마이그레이션 도구와 같은 DBMS 네이티브 복제 기술을 사용하여 새 배포된 인프라로 SAP 환경을 마이그레이션하려면 SAP 시스템에 대한 확립된 기술 지식을 사용합니다.

  • 인프라 확장. SAP 마이그레이션 중에 더 많은 인프라 용량을 보유하면 더 빠르게 배포하는 데 도움이 될 수 있습니다. 프로젝트 팀은 더 많은 CPU 및 메모리를 제공하기 위해 VM 크기를 확장하는 것을 고려해야 합니다. 또한 팀은 VM 집계 스토리지 및 네트워크 처리량을 확장하는 것도 고려해야 합니다. 마찬가지로 VM 수준에서는 프리미엄 SSD v1에 대한 주문형 버스팅 및 성능 계층으로 처리량을 늘리기 위해 개별 디스크와 같은 스토리지 요소를 고려합니다. 구성된 값 위에 프리미엄 SSD v2를 사용하는 경우 IOPS 및 처리량 값을 늘립니다. NFS 및 SMB 파일 공유를 확대하여 성능 제한을 높입니다. Azure 관리 디스크의 크기는 줄어들 수 없으며 크기, 성능 계층 및 처리량 KPI의 감소는 다양한 냉각 시간을 가질 수 있습니다.

  • 네트워크 및 데이터 복사 최적화. SAP 시스템을 Azure로 마이그레이션하려면 항상 많은 양의 데이터를 이동해야 합니다. 데이터는 데이터베이스 및 파일 백업 또는 복제, 애플리케이션-애플리케이션 데이터 전송 또는 SAP 마이그레이션 내보내기일 수 있습니다. 사용하는 마이그레이션 프로세스에 따라 데이터를 이동하려면 올바른 네트워크 경로를 선택해야 합니다. 많은 데이터 이동 작업의 경우 프라이빗 네트워크 대신 인터넷을 사용하는 것이 데이터를 Azure Storage에 안전하게 복사하는 가장 빠른 경로입니다.

    ExpressRoute 또는 VPN을 사용하면 병목 현상이 발생할 수 있습니다.

    • 마이그레이션 데이터는 너무 많은 대역폭을 사용하며 Azure에서 실행되는 워크로드에 대한 사용자 액세스를 방해합니다.
    • 방화벽 또는 처리량 제한과 같은 온-프레미스 네트워크 병목 현상은 마이그레이션 중에만 검색되는 경우가 많습니다.

    사용되는 네트워크 연결에 관계없이 데이터 이동에 대한 단일 스트림 네트워크 성능은 종종 낮습니다. 여러 TCP 스트림에 대한 데이터 전송 속도를 높이려면 여러 스트림을 지원할 수 있는 도구를 사용합니다. SAP 설명서 및 이 항목의 많은 블로그 게시물에 설명된 최적화 기술을 적용합니다.

팁

계획 단계에서는 Azure로의 대규모 데이터 전송에 사용할 전용 마이그레이션 네트워크를 고려하는 것이 중요합니다. 예를 들어 백업 또는 데이터베이스 복제 또는 Azure Storage로의 데이터 전송을 위해 퍼블릭 엔드포인트를 사용하는 것이 포함됩니다. 마이그레이션이 사용자 및 애플리케이션의 네트워크 경로에 미치는 영향을 예상 및 완화해야 합니다. 네트워크 계획의 일환으로 마이그레이션의 모든 단계와 마이그레이션 중에 Azure에서 부분적으로 생산적인 워크로드의 비용을 고려합니다.

SAP에 대한 지원 및 작업

Azure에서 SAP를 배포하기 전과 배포 중에 고려해야 할 몇 가지 다른 영역이 있습니다.

SAP용 Azure VM 확장

Azure 모니터링 확장, 향상된 모니터링 및 SAP용 Azure 확장은 모두 SAP 호스트 에이전트에 Azure 인프라에 대한 몇 가지 기본 데이터를 제공하기 위해 배포해야 하는 VM 확장을 참조합니다. 확장은 SAP 노트에서 모니터링 확장 또는 향상된 모니터링으로 언급될 수 있습니다. Azure에서는 SAP용 Azure 확장이라고 합니다. 지원을 위해 SAP 워크로드를 실행하는 모든 Azure VM에 확장을 설치해야 합니다. 자세한 내용은 SAP용 Azure VM 확장을 참조하세요.

SAP 지원용 SAProuter

Azure에서 SAP 환경을 운영하려면 지원을 위해 SAP와 연결해야 합니다. 일반적으로 연결은 인터넷을 통한 암호화 네트워크 채널을 통해 또는 SAP에 대한 프라이빗 VPN 연결을 통해 SAProuter 연결 형식입니다. 모범 사례 및 Azure의 SAProuter 구현 예제는 Azure의 SAP에 대한 인바운드 및 아웃바운드 인터넷 연결의 아키텍처 시나리오를 참조하세요.

다음 단계