다음을 통해 공유

SAP 워크로드용 Azure Virtual Machines DBMS 배포 시 고려 사항

  • 아티클

이 가이드는 Microsoft Azure에서의 SAP 소프트웨어 구현 및 배포하는 방법에 대한 설명서의 일부입니다. 이 가이드를 읽기 전에 계획 및 구현 가이드와 계획 가이드에서 안내하는 문서를 참조하세요. 이 문서에서는 Azure IaaS(서비스 제공 인프라) 기능을 사용하여 Microsoft Azure VM(Virtual Machines)에서 SAP 관련 DBMS 시스템의 일반적인 배포 측면에 대해 설명합니다.

이 문서는 지정된 플랫폼에서 SAP 소프트웨어 설치 및 배포에 대한 기본 리소스를 나타내는 SAP 설치 설명서 및 SAP 정보를 보완합니다.

이 문서에서는 Azure VM에서 SAP 관련 DBMS 시스템을 실행할 때 고려해야 할 사항을 소개합니다. 이 문서에는 특정 DBMS 시스템에 대한 참조가 거의 없습니다. 대신 특정 DBMS 시스템은 다른 데이터베이스 시스템 특정 문서에서 처리됩니다.

리소스

Azure의 SAP 워크로드에 사용할 수 있는 다른 문서가 있습니다. Azure의 SAP 워크로드: 시작을 시작한 다음 관심 영역을 선택합니다.

이 문서에서 다루는 영역에 대해 Azure의 SAP와 관련된 SAP Note는 다음과 같습니다.

Note 번호 타이틀
1928533 Azure의 SAP 애플리케이션: 지원 제품 및 Azure VM 유형
2015553 Microsoft Azure의 SAP: 지원 필수 조건
1999351 SAP용 고급 Azure 모니터링 문제 해결
2178632 Microsoft Azure의 SAP용 주요 모니터링 메트릭
1409604 Windows에서의 가상화: 향상된 모니터링
2191498 Azure와 Linux의 SAP: 향상된 모니터링
2039619 Oracle Database를 사용하는 Microsoft Azure의 SAP 애플리케이션: 지원 제품 및 버전
2233094 DB6: Linux, UNIX 및 Windows용 IBM DB2를 사용하는 SAP 애플리케이션 - 추가 정보
2243692 Microsoft Azure(IaaS) VM의 Linux: SAP 라이선스 문제
2578899 SUSE Linux Enterprise Server 15: 설치 참고
1984787 SUSE LINUX Enterprise Server 12: 설치 참고
2772999 Red Hat Enterprise Linux 8.x: 설치 및 구성
2002167 Red Hat Enterprise Linux 7.x: 설치 및 업그레이드
2069760 Oracle Linux 7.x SAP 설치 및 업그레이드
1597355 Linux에 대한 스왑 공간 권장 사항
2799900 Oracle Database 19c에 대한 중앙 기술 참고 사항
2171857 Oracle Database 12c: Linux에서 파일 시스템 지원
1114181 Oracle Database 11g: Linux에서 파일 시스템 지원
2969063 Azure의 HCMT에서 마이크로코드 유효성 검사 실패
3246210 Azure - 일부 디스크 성능 테스트 중 HCMT 실패

모든 Linux의 SAP 참고에 대한 자세한 내용은 SAP 커뮤니티 WIKI를 참조하세요.

Microsoft Azure 아키텍처 및 Microsoft Azure Virtual Machines 배포와 작동 방법에 대한 실무 지식이 있어야 합니다. 자세한 내용은 Azure 설명서를 참조하세요.

일반적으로 Windows, Linux 및 DBMS 설치와 구성은 기본적으로 온-프레미스에 설치하는 가상 머신 또는 운영 체제 미설치 머신과 동일합니다. Azure IaaS를 사용하는 경우와 다른 몇 가지 아키텍처와 시스템 관리 구현 결정이 있습니다. 이 문서에서는 Azure IaaS를 사용할 때 준비할 특정 아키텍처 및 시스템 관리 차이점에 대해 설명합니다.

RDBMS 배포를 위한 VM의 스토리지 구조

이 챕터를 수행하려면 다음에서 제공된 정보를 읽고 이해합니다.

Azure 블록 스토리지의 경우, Azure 관리 디스크를 사용해야 합니다. Azure 관리 디스크에 대한 자세한 내용은 Azure VM용 관리 디스크 소개 문서를 참조하세요.

기본 구성에서는 일반적으로 운영 체제, DBMS 및 최종 SAP 이진 파일이 데이터베이스 파일과 분리된 배포 구조를 사용하는 것이 좋습니다. 다음과 같은 경우에는 별도의 Azure 디스크를 사용하는 것이 좋습니다.

  • 운영 체제(기본 VHD 또는 OS VHD)
  • 데이터베이스 관리 시스템 실행 파일
  • /usr/sap와 같은 SAP 실행 파일
  • DBMS 데이터 파일
  • DBMS 다시 실행 로그 파일

이러한 구성 요소를 5개의 서로 다른 볼륨으로 구분하는 구성은 복원력이 높아질 수 있습니다. VM 스토리지 할당량 및 제한을 초과하지 않는 한, 볼륨 하나의 과도한 사용이 다른 볼륨의 사용을 반드시 방해하지는 않기 때문입니다.

DBMS 데이터 및 트랜잭션/다시 실행 로그 파일은 Azure 지원 블록 스토리지 또는 Azure NetApp Files에 저장됩니다. Azure Files 또는 Azure Premium Files는 SAP 워크로드가 있는 DBSM 데이터 및/또는 다시 실행 로그 파일의 스토리지로 지원되지 않습니다. 이러한 이미지는 별도의 디스크에 저장되며 원래 Azure 운영 체제 이미지 VM에 논리 디스크로 연결됩니다. Linux 배포의 경우 다양한 권장 사항이 문서화되어 있습니다. 사용자 시나리오에 대한 다양한 스토리지 유형의 기능 및 지원에 대한 SAP 워크로드에 대한 Azure Storage 유형 문서를 참조하세요. 특히 SAP HANA의 경우 SAP HANA Azure 가상 머신 스토리지 구성 문서부터 시작합니다.

디스크 레이아웃을 계획할 때 다음 항목에 가장 잘 맞는 레이아웃을 찾습니다.

  • 데이터 파일 수
  • 파일에 포함된 디스크 수
  • 단일 디스크 또는 NFS 공유의 IOPS 할당량
  • 디스크 또는 NFS 공유 당 데이터 처리량.
  • VM 크기당 가능한 추가 데이터 디스크 수
  • VM에서 제공할 수 있는 전체 스토리지 또는 네트워크 처리량
  • 다양한 Azure Storage 유형에서 제공할 수 있는 대기 시간
  • VM 스토리지 IOPS 및 처리량 할당량.
  • NFS를 사용하는 경우 VM 네트워크 할당량 - NFS 공유에 대한 트래픽은 스토리지 할당량이 아닌 VM의 네트워크 할당량에 대해 계산됩니다.
  • VM SLA

Azure는 데이터 디스크 또는 NFS 공유 당 IOPS 할당량을 적용합니다. 다양한 Azure 블록 스토리지 솔루션 또는 공유에서 호스트되는 디스크에 대한 이러한 할당량은 다양합니다. I/O 대기 시간도 이러한 다양한 스토리지 유형 간에도 다릅니다.

각 VM 유형에는 연결할 수 있는 데이터 디스크 수가 제한되어 있습니다. 또 다른 제한은 특정 VM 유형만이 Premium Storage 등을 사용할 수 있다는 것입니다. 일반적으로 CPU 및 메모리 요구 사항을 기반으로 특정 VM 유형을 사용하기로 결정합니다. 또한 일반적으로 디스크 수 또는 Premium Storage 디스크 v1 유형으로 크기를 조정하는 IOPS, 대기 시간 및 디스크 처리량 요구 사항을 고려해야 합니다. IOPS 수 및 각 디스크에서 수행할 처리량에 따라 디스크 크기가 결정될 수 있습니다(특히 Premium Storage v1의 경우). Premium Storage v2 또는 Ultra 디스크를 사용하면 디스크 용량과 독립적으로 프로비전된 IOPS 및 처리량을 선택할 수 있습니다.

참고 항목

DBMS 배포의 경우, 데이터, 트랜잭션 로그 또는 다시 실행 파일에 대해 Azure Premium Storage(v1 및 v2), Ultra 디스크 또는 Azure NetApp Files 기반 NFS 공유를 사용하는 것이 좋습니다. 프로덕션 또는 비프로덕션 시스템을 배포할지는 중요하지 않습니다. Azure 표준 HDD 또는 SSD의 대기 시간은 모든 유형의 프로덕션 시스템에 허용되지 않습니다.

참고 항목

Azure의 단일 VM SLA를 활용하려면, 연결된 모든 디스크가 Azure Premium Storage(v1 또는 v2) 또는 기본 VHD(Azure Premium Storage)를 포함하는 Azure Ultra 디스크 유형이어야 합니다.

참고 항목

Azure 데이터 센터 근처에 공동 배치된 타사 데이터 센터에 있는 스토리지 하드웨어에서 SAP 데이터베이스의 기본 데이터베이스 파일(예: 데이터 및 로그 파일)을 호스트할 수는 없습니다. Azure VM에서 호스트되는 소프트웨어 어플라이언스를 통해 제공되는 스토리지도 이러한 사용 사례에 지원되지 않습니다. SAP DBMS 워크로드의 경우에는 기본 Azure 서비스로 표시되는 스토리지에서만 일반적으로 SAP 데이터베이스의 데이터 및 트랜잭션 로그 파일을 호스트할 수 있습니다. 여러 DBMS가 다양한 Azure Storage 유형을 지원할 수 있습니다. 자세한 내용은 SAP 워크로드에 대한 Azure Storage 유형 문서를 참조하세요.

데이터베이스 파일 및 로그/다시 실행 파일의 배치와 사용하는 Azure Storage 유형은 IOPS, 대기 시간 및 처리량 요구 사항에 따라 정의됩니다. 특히 Azure Premium Storage v1의 경우, 충분한 IOPS를 달성하기 위해 여러 디스크를 사용하거나 더 큰 Premium Storage 디스크를 사용해야 할 수도 있습니다. 여러 디스크를 사용하는 경우 데이터 파일 또는 로그 및 다시 실행 파일을 포함하는 디스크에서 소프트웨어 스트라이프를 작성합니다. 이러한 경우 기본 Premium Storage 디스크의 IOPS 및 디스크 처리량 SLA 또는 Standard Storage 디스크의 달성 가능한 최대 IOPS가 결과 스트라이프 세트에 누적됩니다.

단일 VHD에서 제공할 수 있는 IOPS 요구 사항을 초과하는 경우, 여러 VHD에서 데이터베이스 파일에 필요한 IOPS의 균형을 조정합니다. IOPS 부하를 디스크에 분산시키는 가장 쉬운 방법은 서로 여러 디스크에 소프트웨어 스트라이프를 빌드하는 것입니다. 그런 다음, SAP DBMS의 여러 데이터 파일을 소프트웨어 스트라이프에서 얻은 LUN에 배치합니다. 스트라이프의 디스크 수는 IOPS, 디스크 처리량 및 볼륨 요구 사항에 따라 결정됩니다.

Windows 스토리지 스트라이프 Windows

Windows 스토리지 공간을 사용하여 여러 Azure VHD에 스트라이프 세트를 만드는 것이 좋습니다. 최소 Windows Server 2012 R2 또는 Windows Server 2016을 사용합니다.

Linux 스토리지 스트라이프 Linux

Linux에서 소프트웨어 RAID를 빌드하는 경우 MDADM 및 LVM(논리 볼륨 관리자)만 지원됩니다. 자세한 내용은 다음을 참조하세요.

Azure Premium Storage v2 및 Ultra 디스크의 경우, IOPS 및 디스크 처리량을 디스크 크기와 독립적으로 정의할 수 있으므로 스트라이프를 사용할 필요가 없습니다.

참고 항목

Azure Storage는 VHD의 이미지 3개를 유지하므로 스트라이핑할 때 중복성을 구성하는 것은 적합하지 않습니다. I/O가 서로 다른 VHD를 통해 분산되도록 스트라이핑을 구성하기만 하면 됩니다.

관리되거나 관리되지 않는 디스크

Azure Storage 계정은 관리 구성 요소일뿐 아니라 제한의 대상이 됩니다. 기능 및 제한 사항에 대한 자세한 내용은 Azure Storage 확장성 및 성능 목표를 참조하세요. Standard Storage의 경우 스토리지 계정당 IOPS에 제한이 있다는 점에 주의하세요. Azure Storage 확장성 및 성능 목표 문서에서 총 요청 비율이 포함된 행을 참조하세요. Azure 구독당 스토리지 계정 수의 초기 제한도 있습니다. 2017년 기준으로 Azure는 스토리지 계정 관리에 대한 부담을 덜기 위해 Azure Managed Disks 개념을 도입했습니다. Azure 관리 디스크를 사용하는 것은 Azure에서 SAP 워크로드에 대해 배포하기 위한 기본값입니다.

Important

Azure Managed Disks의 이점을 고려할 때 일반적으로 DBMS 배포 및 SAP 배포에 Azure Managed Disks를 사용하는 것은 필수입니다.

아직 관리 디스크를 사용하지 않는 SAP 워크로드가 있는 경우 관리되지 않는 디스크에서 변환하려면 다음을 참조하세요.

VM 및 데이터 디스크에 대한 캐싱

VM에 디스크를 탑재할 때 VM과 Azure Storage에 있는 디스크 간의 I/O 트래픽을 캐시할지 여부를 선택할 수 있습니다.

다음 권장 사항은 표준 DBMS에 대한 이러한 I/O 특성을 가정합니다.

  • 대부분 데이터베이스의 데이터 파일에 대한 읽기 작업입니다. 이러한 읽기는 DBMS 시스템의 성능에 중요합니다.
  • 데이터 파일에 대한 쓰기는 검사점 또는 상수 스트림에 따라 갑자기 발생합니다. 하루 평균, 읽기보다 쓰기 수가 적습니다. 데이터 파일의 읽기와 반대되는 이러한 쓰기는 비동기적이며 어떤 사용자 트랜잭션도 보류하지 않습니다.
  • 트랜잭션 로그 또는 다시 실행 파일에 대한 읽기는 거의 없습니다. 트랜잭션 로그 백업 수행 시의 큰 I/O는 예외입니다.
  • 트랜잭션 또는 다시 실행 로그 파일에 대한 주요 부하는 쓰기입니다. 워크로드의 특성에 따라 4KB 정도의 작은 I/O가 있거나, 다른 경우에 1MB 이상의 I/O 크기가 있을 수 있습니다.
  • 모든 쓰기는 신뢰할 수 있는 방식으로 디스크에서 유지되어야 합니다.

Azure Premium Storage v1의 경우 캐싱 옵션은 다음과 같습니다.

  • 없음
  • 읽기
  • 읽기/쓰기
  • 없음 + Write Accelerator(Azure M 시리즈 VM에만 해당)
  • 읽기 + Write Accelerator(Azure M 시리즈 VM에만 해당)

Premium Storage v1의 경우 SAP 데이터베이스의 데이터 파일에 대한 읽기 캐싱을 사용하고 로그 파일의 디스크에 대한 캐싱 없음을 선택하는 것이 좋습니다.

참고 항목

일부 새 M(b)v3 VM 유형을 사용하면 읽기 캐시된 Premium SSD v1 스토리지를 사용하면 읽기 캐시를 사용하지 않는 경우 얻을 수 있는 것보다 읽기 및 쓰기 IOPS 속도 및 처리량이 낮아질 수 있습니다.

M 시리즈 배포의 경우 로그 파일의 디스크에만 Azure Write Accelerator를 사용하는 것이 좋습니다. Azure Write Accelerator에 대한 세부 정보, 제한 및 배포는 Write Accelerator 사용을 참조하세요.

Premium Storage v2, Ultra 디스크 및 Azure NetApp Files의 경우 캐싱 옵션이 제공되지 않습니다.

Azure 비영구 디스크

VM이 배포되면 Azure VM에서 비영구 디스크를 제공합니다. VM이 다시 부팅되면 해당 드라이브의 모든 콘텐츠가 지워질 수 있습니다. 데이터베이스의 데이터 파일과 로그/다시 실행 파일은 어떤 경우에도 이러한 비영구 드라이브에 배치하면 안 됩니다. 이러한 비영구 드라이브가 tempdb 및 temp 테이블 공간에 적합할 수 있는 일부 데이터베이스에는 예외가 있을 수 있습니다.

자세한 내용은 Azure의 Windows VM에서 임시 드라이브 이해를 참조하세요.

Windows 비사용 디스크 Windows

Azure VM의 드라이브 D는 Azure 컴퓨팅 노드의 일부 로컬 디스크에서 지원하는 비지속형 드라이브입니다. 비지속형이므로 D 드라이브의 콘텐츠에 대한 변경 내용은 VM을 재부팅하면 손실됩니다. 변경 내용에는 저장된 파일, 생성된 디렉터리, 설치된 애플리케이션이 포함됩니다.

Linuxnonpersisted 디스크 Linux

Linux Azure VM은 Azure 컴퓨팅 노드의 로컬 디스크에서 지원하는 비지속형 드라이브의 /mnt/resource에 자동으로 탑재됩니다. 비지속형이므로 /mnt/resource의 콘텐츠에 대한 변경 내용은 VM을 재부팅하면 손실됩니다. 변경 내용에는 저장된 파일, 생성된 디렉터리, 설치된 애플리케이션이 포함됩니다.

Microsoft Azure Storage 복원력

Microsoft Azure Storage는 최소 3개의 별도 스토리지 노드에 기본 VHD(OS 포함) 및 연결된 디스크 또는 Blob을 저장합니다. 이 스토리지 유형을 LRS(로컬 중복 스토리지)라고 합니다. LRS는 Azure의 모든 스토리지 유형에 대한 기본값입니다.

다른 중복 방법이 있습니다. 자세한 내용은 Azure Storage 복제를 참조하세요.

참고 항목

Azure Premium Storage v1 및 v2, Ultra 디스크 및 Azure NetApp Files는 데이터베이스와 로그 및 다시 실행 파일을 저장하는 DBMS VM 및 디스크에 권장되는 스토리지 유형입니다. Premium Storage v1을 제외하고 이러한 스토리지 유형에 사용할 수 있는 유일한 중복 방법은 LRS입니다. 따라서 데이터베이스 데이터 복제를 다른 Azure 지역 또는 가용성 영역으로 설정하도록 데이터베이스 메서드를 구성해야 합니다. 데이터베이스 메서드에는 SQL Server Always On, Oracle Data Guard 및 HANA 시스템 복제가 포함됩니다.

VM 노드 복원력

Azure는 VM에 대해 여러 가지 SLA를 제공합니다. 자세한 내용은 Virtual Machines에 대한 SLA의 최신 릴리스를 참조하세요. DBMS 계층은 SAP 시스템의 가용성에 매우 중요하므로 다양한 배포 유형과 유지 관리 이벤트를 이해해야 합니다. 이러한 개념에 대한 자세한 내용은 Azure에서 가상 머신의 가용성 관리를 참조하세요.

SAP 워크로드를 사용하는 프로덕션 DBMS 시나리오에 대한 최소 권장 사항은 다음과 같습니다.

  • 동일한 Azure 지역에 선택한 배포 유형을 사용하여 두 개의 VM을 배포합니다.
  • 동일한 Azure 가상 네트워크에서 이 두 VM을 실행하고 동일한 서브넷에서 NIC를 연결합니다.
  • 데이터베이스 메서드를 사용하여 두 번째 VM에 대한 상시 대기를 유지합니다. 메서드는 SQL Server Always On, Oracle Data Guard 또는 HANA System Replication일 수 있습니다.

또한 다른 Azure 지역에 세 번째 VM을 배포하고, 동일한 데이터베이스 메서드를 사용하여 다른 Azure 지역에 비동기 복제본을 제공할 수 있습니다.

Azure 네트워크 고려 사항

대규모 SAP 배포에서는 Azure 가상 데이터 센터의 청사진을 사용합니다. 가상 네트워크 구성 및 조직의 다른 부분에 대한 사용 권한 및 역할 할당에 사용합니다.

다음 모범 사례는 수천 명의 고객 배포에 대한 결과입니다.

  • SAP 애플리케이션이 배포된 가상 네트워크는 인터넷에 액세스할 수 없습니다.
  • 데이터베이스 VM은 애플리케이션 계층과 동일한 가상 네트워크에서 실행되고, SAP 애플리케이션 계층과는 다른 서브넷으로 구분됩니다.
  • 가상 네트워크 내의 VM에는 개인 IP 주소의 정적 할당이 있습니다. 자세한 내용은 Azure에서 IP 주소 형식 및 할당 메서드를 참조하세요.
  • DBMS VM 간의 라우팅 제한은 로컬 DBMS VM에 설치된 방화벽으로 설정되지 않습니다. 대신 트래픽 라우팅은 NSG(네트워크 보안 그룹)로 정의됩니다.
  • 트래픽을 DBMS VM으로 분리하고 격리하려면 다른 NIC를 VM에 할당합니다. 모든 NIC는 서로 다른 IP 주소를 가지며 모든 NIC는 다른 가상 네트워크 서브넷에 할당됩니다. 모든 서브넷의 NSG 규칙은 서로 다릅니다. 네트워크 트래픽 격리 또는 분리는 라우팅에 대한 측정값입니다. 네트워크 처리량에 대한 할당량을 설정하는 데 사용되지 않습니다.

참고 항목

Azure를 통해 고정 IP 주소를 할당하는 것은 개별 가상 NIC에 할당하는 것을 의미합니다. 게스트 OS 내에서 고정 IP 주소를 vNIC에 할당하지 않아야 합니다. Azure Backup과 같은 일부 Azure 서비스는 게스트 OS에서 최소한 기본 가상 NIC가 고정 IP 주소가 아닌 DHCP로 설정된다는 사실에 의존합니다. 자세한 내용은 Azure Virtual Machine 백업 문제 해결을 참조하세요. VM에 여러 개의 고정 IP 주소를 할당하려면 여러 가상 NIC를 VM에 할당합니다.

Warning

SAP 애플리케이션과 SAP NetWeaver, Hybris 또는 S/4HANA 기반 SAP 시스템의 DBMS 계층 사이의 통신 경로에 네트워크 가상 어플라이언스를 구성하는 것은 지원되지 않습니다. 이러한 제한 사항은 기능 및 성능 때문입니다. SAP 애플리케이션 계층과 DBMS 계층 간의 통신 경로는 직접 통신이어야 합니다. ASG 및 NSG 규칙에서 직접 통신 경로를 허용하는 경우에는 해당 ASG(애플리케이션 보안 그룹) 및 NSG 규칙이 제한에 포함되지 않습니다. 여기에는 DBMS 데이터 및 다시 실행 로그 파일을 호스트하는 NFS 공유에 대한 트래픽도 포함됩니다.

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

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

Important

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

권장 사항을 따르지 않고 두 계층을 다른 가상 네트워크로 분리하려는 경우에는 두 가상 네트워크가 피어링되어야 합니다.

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

Azure Load Balancer를 사용하여 트래픽 리디렉션

SQL Server Always On 또는 HANA System Replication과 같은 기능에 사용되는 개인 가상 IP 주소를 사용하려면 Azure Load Balancer를 구성해야 합니다. Load Balancer는 프로브 포트를 사용하여 활성 DBMS 노드를 결정하고 해당 활성 데이터베이스 노드로만 트래픽을 라우팅할 수 있습니다.

데이터베이스 노드를 장애 조치(failover)하는 경우 SAP 애플리케이션을 다시 구성할 필요가 없습니다. 대신 가장 일반적인 SAP 애플리케이션 아키텍처가 개인 가상 IP 주소에 다시 연결됩니다. 한편 부하 분산 장치는 개인 가상 IP 주소에 대한 트래픽을 두 번째 노드로 리디렉션하여 노드 장애 조치(failover)에 대응했습니다.

Azure는 기본 SKU와 표준 SKU의 두 가지 부하 분산 장치 SKU를 제공합니다. 설정 및 기능의 이점에 따라 Azure 부하 분산 장치의 표준 SKU를 사용해야 합니다. 부하 분산 장치의 표준 버전의 큰 이점 중 하나는 데이터 트래픽이 부하 분산 장치 자체를 통해 라우팅되지 않는다는 것입니다.

내부 부하 분산 장치를 구성하는 방법의 예는 자습서: Azure Virtual Machines에서 수동으로 SQL Server 가용성 그룹 구성 문서에서 찾을 수 있습니다.

참고 항목

공용 IP 주소의 액세스와 관련된 기본 및 표준 SKU의 동작에 차이점이 있습니다. 공용 IP 주소에 액세스하는 표준 SKU의 제한을 해결하는 방법은 SAP 고가용성 시나리오에서 Azure 표준 Load Balancer를 사용하여 Virtual Machines에 대한 공용 엔드포인트 연결 문서에 설명되어 있습니다.

호스트 모니터링 배포

Azure Virtual Machines에서 SAP 애플리케이션을 프로덕션에 사용하려면 Azure Virtual Machines를 실행하는 실제 호스트에서 호스트 모니터링 데이터를 가져올 수 있는 기능이 필요합니다. SAPOSCOL 및 SAP HostAgent에서 이 기능을 사용하려면 특정 SAP HostAgent 패치 수준이 필요합니다. 정확한 패치 수준은 SAP Note 1409604에 설명되어 있습니다.

SAPOSCOL 및 SAP 호스트 에이전트에 호스트 데이터를 전달하는 구성 요소의 배포 및 이러한 구성 요소의 수명 주기 관리에 대한 자세한 내용은 SAP 솔루션에 대한 Azure VM 확장 구현 문서를 참조하세요.

다음 단계

특정 DBMS에 대한 자세한 내용은 다음을 참조하세요.