다음을 통해 공유

Azure 가용성 영역을 사용하는 SAP 워크로드 구성

  • 아티클

Azure 가용성 영역 여러 SAP 아키텍처 계층을 배포하는 것이 Azure의 SAP 워크로드 배포에 권장되는 아키텍처입니다. Azure 가용성 영역은 다음과 같이 정의됩니다. “지역 내의 고유한 물리적 위치입니다. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다.” Azure 가용성 영역을 모든 지역에서 사용할 수 있는 것은 아닙니다. Azure에서 가용성 영역을 제공하는 지역에 대해서는 Azure 지역 맵에서 확인하세요. 이 문서에서는 가용성 영역 제공하는 지역을 나열합니다. 더 큰 SAP 워크로드를 호스트할 수 있는 대부분의 Azure 지역은 가용성 영역 제공합니다. 새 Azure 지역은 처음부터 가용성 영역 제공합니다. 오래된 지역 중 일부는 가용성 영역 개조되는 과정에 있거나 있습니다.

일반적인 SAP NetWeaver 또는 S/4HANA 아키텍처의 경우라면 다음 세 가지 계층을 보호해야 합니다.

  • SAP 애플리케이션 계층은 1~12개의 VM(Virtual Machines)일 수 있습니다. VM이 동일한 호스트 서버에 배포될 가능성을 최소화하려고 합니다. 또한 데이터베이스 계층에 대한 허용 가능한 근접에 있는 해당 VM이 허용 가능한 창에서 네트워크 대기 시간을 유지하도록 합니다.
  • SAP NetWeaver 및 S/4HANA 아키텍처에서 단일 실패 지점을 나타내는 SAP ASCS/SCS 계층입니다. 일반적으로는 장애 조치 프레임워크를 통해 처리할 VM 두 개를 확인합니다. 따라서 이러한 VM은 서로 다른 인프라 장애 도메인에 할당되어야 합니다.
  • 단일 실패 지점을 나타내는 SAP 데이터베이스 계층입니다. 일반적인 경우라면 장애 조치 프레임워크에 의해 적용되는 VM 두 개로 구성됩니다. 따라서 이러한 VM은 서로 다른 인프라 장애 도메인에 할당되어야 합니다. VM을 세 개 이상 사용할 수 있는 경우의 SAP HANA 스케일 아웃 배포는 예외입니다.

가용성 집합을 통해 중요한 VM을 배포할 때와 가용성 영역을 통해 이를 배포할 때의 주요 차이점은 다음과 같습니다.

  • 가용성 집합을 이용한 배포의 경우, 특정 지역에서 적용되는 것이라면 무엇이든 단일 구역이나 데이터 센터의 집합 내에서 VM을 정렬합니다. 결과적으로 가용성 집합을 통한 배포는 영역 전체의 데이터 센터에 영향을 주는 전원, 냉각 또는 네트워킹 문제로 보호되지 않습니다. 가용성 집합을 사용하면 VM과 해당 디스크 간에 강제 맞춤이 없습니다. 즉, 디스크는 지역의 영역 구조와 관계없이 Azure 지역의 모든 데이터 센터에 있을 수 있습니다. 긍정적인 면은 VM가 해당 영역이나 데이터 센터 내의 업데이트 및 장애 도메인에 맞춰진다는 점입니다. 특히 가용성 집합당 두 개의 VM을 보호하는 SAP ASCS 또는 데이터베이스 계층의 경우 장애 도메인과의 맞춤을 통해 두 VM이 동일한 호스트 하드웨어에서 종료되는 것을 방지할 수 있습니다.
  • Azure 가용성 영역 통해 VM을 배포하고 다른 영역(최대 3개 가능)을 선택하면 여러 물리적 위치에 VM을 배포할 예정이며, 이를 통해 영역 전체의 데이터 센터에 영향을 주는 전원, 냉각 또는 네트워킹 문제로부터 보호를 추가할 수 있습니다. VM 및 관련 디스크도 동일한 가용성 영역에 공동 배치됩니다. 하지만 동일한 가용성 영역에 같은 VM 제품군의 VM을 둘 이상 배포하는 경우, 동일 호스트 또는 동일 장애 도메인에 있게 되는 VM으로부터 보호되지 않습니다. 따라서 가용성 영역 통해 배포하는 것은 일반적으로 각각 두 개의 VM을 살펴보는 SAP ASCS 및 데이터베이스 계층에 적합합니다. 두 개 이상의 VM이 될 수 있는 SAP 애플리케이션 계층의 경우 다른 배포 모델로 대체해야 할 수 있습니다(나중에 참조).

중요한 단일 VM의 실패를 처리하거나 중요한 소프트웨어 패치의 가동 중지 시간을 줄이는 기능 외에도 하나 이상의 Azure 데이터 센터의 가용성에 영향을 줄 수 있는 대형 인프라 문제를 방지하고자 하는 것이 Azure 가용성 영역에 걸친 배포 동기여야 합니다.

Azure는 또 다른 복원력 배포 기능으로 SAP 워크로드를 위한 유연한 오케스트레이션 기능이 있는 Virtual Machine Scale Sets를 도입했습니다. Virtual Machine Scale Sets는 플랫폼 관리형 가상 머신의 논리적 그룹화를 제공합니다. Virtual Machine Scale Set의 유연한 오케스트레이션은 지역 내에서 확장 집합을 만들거나 가용성 영역 전체에 걸쳐 확장하는 옵션을 제공합니다. PlatformFaultDomainCount>1(FD>1)이 있는 지역 내에서 유연한 확장 집합을 만들 때 확장 집합에 배포된 VM은 동일한 지역의 지정된 수의 장애 도메인에 분산됩니다. 반면에 platformFaultDomainCount=1(FD=1)을 사용하여 가용성 영역에 걸쳐 유연한 확장 집합을 만들면 여러 영역에 가상 머신을 분산하고, 확장 집합은 최상의 노력으로 각 영역 내의 여러 장애 도메인에 VM을 분산합니다. SAP 워크로드의 경우 FD=1이 설정된 유연한 확장 집합만 지원됩니다. 기존 가용성 영역 배포 대신 영역 간 배포에 FD=1이 설정된 유연한 확장 집합을 사용할 경우의 이점은 확장 집합과 함께 배포된 VM이 최상의 방식으로 영역 내의 여러 장애 도메인에 분산된다는 점입니다. 자세한 내용은 SAP 워크로드에 대한 유연한 확장 집합의 배포 가이드를 참조하세요.

가용성 영역에 걸쳐 배포할 때의 고려 사항

가용성 영역을 사용하는 경우 다음을 고려합니다.

  • Azure 가용성 영역 대한 자세한 내용은 문서 지역 및 가용성 영역에 제공됩니다.
  • 숙련된 네트워크 왕복 대기 시간이 반드시 다른 영역을 형성하는 데이터 센터의 실제 지리적 거리를 나타내는 것은 아닙니다. 네트워크 왕복 대기 시간은 케이블 연결 및 서로 다른 데이터 센터 간 케이블 라우팅의 영향도 받습니다.
  • 가용성 영역 소거리 DR 솔루션으로 사용하는 경우 전력 인프라에 대한 무겁고 광범위한 손상을 포함하여 전 세계 여러 지역에서 광범위한 피해를 초래하는 자연 재해가 발생했음을 명심하세요. 다양한 영역 사이의 거리가 항상 그렇게 큰 자연 재해를 보상하기에 충분히 크지 않을 수 있습니다.
  • 가용성 영역 간의 네트워크 대기 시간이 모든 Azure 지역에서 동일하지는 않습니다. Azure 지역 내에서도 서로 다른 영역 간의 네트워크 대기 시간은 다를 수 있습니다. 최악의 경우에도 HANA 시스템 복제 또는 SQL Server Always On을 기반으로 하는 데이터베이스 수준의 동기 복제는 워크로드의 확장성에 영향을 주지 않고 작동합니다.
  • 가용성 영역을 사용할 위치를 결정할 때는 영역 간 네트워크 대기 시간을 고려합니다. 네트워크 대기 시간은 다음과 같이 두 가지 영역에서 중요한 역할을 합니다.
    • 동기 복제가 필요한 두 데이터베이스 인스턴스 간의 대기 시간. 네트워크 대기 시간이 1.5밀리초 미만인 영역 간에 가장 큰 NetWeaver 및 S/4HANA 시스템의 성공적인 운영을 기반으로 이 고려 사항을 무시할 수 있습니다.
    • 활성 데이터베이스 인스턴스가 있는 영역에서 SAP 대화 상자 인스턴스를 실행하는 VM과 다른 영역에 있는 유사한 VM 간의 네트워크 대기 시간 차이입니다. 이러한 차이가 증가함에 따라 비즈니스 프로세스 및 일괄 처리 작업의 실행 시간에 대한 영향도 데이터베이스와 함께 영역 내 또는 다른 영역에서 실행되는지 여부에 따라 증가합니다(이 문서의 뒷부분 참조).
  • Azure 가용성 영역 네트워크 대기 시간은 가장 큰 영역에서도 SAP 비즈니스 프로세스를 실행하기에 충분히 낮습니다. 지금까지 고객이 단일 데이터 센터 네트워크 척추 아래에 SAP 애플리케이션 계층 및 데이터베이스 계층을 공동 배치해야 하는 몇 가지 예외적 사례만 보았습니다.

가용성 영역 간에 Azure VM을 배포하고 동일한 Azure 지역 내에서 장애 조치(failover) 솔루션을 설정할 경우 다음과 같은 몇 가지 제한 사항이 있습니다.

  • Azure 가용성 영역을 배포하는 경우 Azure Managed Disks를 사용해야 합니다.
  • 물리적 영역에 대한 영역 열거형 매핑은 Azure 구독을 기준으로 고정됩니다. 다른 구독을 사용하여 SAP 시스템을 배포하는 경우 구독마다 적절한 영역을 정의해야 합니다. 다른 구독의 논리적 매핑을 비교하려면 Avzone 매핑 스크립트를 고려합니다.
  • Azure 근접 배치 그룹을 사용하지 않으면 Azure 가용성 영역 내에 Azure 가용성 세트를 배포할 수 없습니다. SAP 데이터베이스 계층과 중앙 서비스를 여러 영역에 배포하고 동시에 가용성 집합을 사용하여 SAP 애플리케이션 계층을 배포하고 VM의 근접성을 달성하는 방법은 SAP 애플리케이션과의 네트워크 대기 시간을 최적화하기 위한 Azure 근접 배치 그룹 문서에 설명되어 있습니다. Azure 근접 배치 그룹을 사용하지 않는 경우, 가상 머신용 배포 프레임워크로 둘 중 하나를 선택해야 합니다.
  • Azure 기본 Load Balancer를 사용하여 Windows Server 장애 조치(failover) 클러스터링 또는 Linux Pacemaker를 기반으로 장애 조치(failover) 클러스터 솔루션을 만들 수 없습니다. 대신 Azure 표준 Load Balancer SKU를 사용해야 합니다.
  • 원하는 영역 보호를 얻으려면 ExpressRoute 게이트웨이, VPN Gateway 및 표준 공용 IP 주소의 영역 버전을 배포해야 합니다.

이상적인 가용성 영역 조합

로그온 그룹, RFC 서버 그룹, Batch 서버 그룹 등의 SAP 기능을 사용하여 비즈니스 프로세스 할당을 구성하지 않는 한, SAP 애플리케이션 계층의 여러 애플리케이션 인스턴스에서 비즈니스 프로세스를 실행할 수 있습니다. 이 사실의 부작용은 배치 작업이 활성 데이터베이스 인스턴스와 동일한 영역에서 실행되는지 여부에 관계없이 SAP 애플리케이션 인스턴스에 의해 실행될 수 있다는 것입니다. 각기 다른 영역 간의 네트워크 대기 시간이 동일 영역 내의 네트워크 대기 시간에 비해 적은 경우, 일괄 처리 작업의 런타임끼리의 차이는 미미할 수 있습니다. 그러나 영역 간 네트워크 트래픽에 비해 영역 내의 네트워크 대기 시간 차이가 클수록 데이터베이스 인스턴스가 활성화되지 않은 영역에서 작업이 실행된 경우 일괄 처리 작업의 런타임에 더 많은 영향을 미칠 수 있습니다. 런타임의 차이를 어디까지 허용할 지는 고객이 판단할 사항입니다. 워크로드의 영역 간 트래픽에 대한 네트워크 대기 시간을 어디까지 허용할 지도 마찬가지입니다. 순전히 기술적 관점에서 볼 때 Azure 지역 내의 Azure 가용성 영역 간의 네트워크 대기 시간은 NetWeaver, S/4HANA 또는 기타 SAP 애플리케이션의 아키텍처에서 작동합니다. 또한 이 문서에서 소개하는 배포 개념 중 하나를 결정할 때 로그온 그룹, RFC 서버 그룹, Batch Server 그룹 등의 SAP 개념을 사용하여 이러한 차이를 완화할 수 있는 고객이기도 합니다.

여러 영역에 걸쳐 SAP NetWeaver 또는 S/4HANA 시스템을 배포하고자 하는 경우, 배포할 수 있는 두 가지의 아키텍처 패턴이 있습니다.

  • 활성/활성: ASCS/SCS를 실행하는 VM 쌍과 데이터베이스 계층을 실행하는 VM 쌍은 두 영역에 분산됩니다. SAP 애플리케이션 계층을 실행하는 VM은 동일한 두 영역에 걸쳐 짝수로 배포됩니다. 데이터베이스 또는 ASCS/SCS VM이 장애 조치(failover)되는 경우 열려 있는 트랜잭션과 활성 트랜잭션 중 일부가 롤백될 수 있습니다. 그렇다고 하더라도 사용자는 로그인 상태로 남아 있습니다. 활성 데이터베이스 VM 및 애플리케이션 인스턴스가 실행되는 영역은 중요하지 않습니다. 해당 아키텍처는 여러 영역에 걸쳐 배포할 때 바람직한 아키텍처입니다. 비즈니스 프로세스를 실행할 때 영역 간의 네트워크 대기 시간이 더 큰 차이를 일으키는 경우 SAP 로그온 그룹, RFC 서버 그룹, Batch Server 그룹 등의 기능을 사용하여 비즈니스 프로세스 실행을 활성 데이터베이스 인스턴스와 동일한 영역에 있는 특정 대화 상자 인스턴스로 라우팅할 수 있습니다.
  • 활성/수동: ASCS/SCS를 실행하는 VM 쌍과 데이터베이스 계층을 실행하는 VM 쌍은 두 영역에 분산됩니다. SAP 애플리케이션 계층을 실행하는 VM은 가용성 영역 중 하나에 배포됩니다. 활성 ASCS/SCS 및 데이터베이스 인스턴스와 동일한 영역에서 애플리케이션 계층을 실행합니다. 다른 영역의 네트워크 대기 시간이 너무 높다고 판단되는 경우 이 배포 아키텍처를 사용할 수 있습니다. 이로 인해 비즈니스 프로세스의 런타임에 참을 수 없는 차이가 발생합니다. 또는 가용성 영역 배포를 짧은 거리 DR 배포로 사용하려는 경우 영역입니다. ASCS/SCS 또는 데이터베이스 VM이 보조 영역으로 장애 조치되는 경우 네트워크 대기 시간이 늘어나고 처리량이 감소할 수 있습니다. 처리량을 이전 수준으로 회복하려면 최대한 빨리 이전에 장애 조치(failover)된 VM의 장애를 복구해야 합니다. 영역 중단이 발생할 경우 애플리케이션 계층을 보조 영역으로 장애 조치(failover)해야 합니다. 사용자가 시스템을 완전히 종료할 때 발생하는 작업입니다.

그러므로 가용성 영역을 사용하는 방법을 결정하기 전에는 다음 사항을 확인해야 합니다.

  • Azure 지역의 세 영역 간 네트워크 대기 시간. 영역 내의 구역 간에 발생하는 네트워크 대기 시간에 대해 인지하고 있다면 영역 간 네트워크 트래픽에서 네트워크 대기 시간이 가장 적은 영역을 선택할 수 있습니다.
  • 선택한 영역 중 하나의 VM 간 대기 시간과 선택한 두 영역 간 네트워크 대기 시간의 차이
  • 선택한 두 영역에서 배포 해야 하는 VM 유형을 사용할 수 있는 여부를 결정합니다. 일부 VM, SKU를 사용하는 경우 일부 SKU를 세 영역 중 두 영역에서만 사용할 수 있는 경우가 발생할 수 있습니다.

영역 간 및 영역 내 네트워크 대기 시간

다른 영역 간 대기 시간을 확인하려면 다음을 수행해야 합니다.

  • 세 영역 모두에 데이터베이스 인스턴스에 사용할 VM SKU를 배포합니다. 이러한 측정을 수행할 때 Azure Accelerated Networking을 사용하도록 설정해야 합니다. 가속화된 네트워킹은 몇 년 전부터 기본 설정으로 설정되어 있습니다. 그럼에도 활성화되어 작동하는지 확인하세요.
  • 최소 네트워크 대기 시간을 나타내는 두 영역을 찾으면 세 가용성 영역에 걸쳐 애플리케이션 계층 VM으로 사용하려는 VM SKU의 다른 3개 VM을 배포합니다. 선택한 두 영역의 두 데이터베이스 VM에 대한 네트워크 대기 시간을 측정합니다.
  • niping을 측정 도구로 사용합니다. SAP의 이 도구는 SAP support note #500235 및 #1100926에서 설명합니다. SAP Note #1100926 네트워크 대기 시간 분류를 대략적인 지침으로 처리합니다. 네트워크 대기 시간이 0.7밀리초보다 크다고 해서 시스템이 기술적으로 작동하지 않거나 비즈니스 프로세스가 개별 SLA를 충족하지 않는다는 의미는 아닙니다. 참고는 SAP 및/또는 Microsoft에서 지원되거나 지원되지 않는 내용을 명시하기 위한 것이 아닙니다. 대기 시간 측정에 대한 명령을 중심으로 참조하세요. ping은 Azure Accelerated Networking 코드 경로를 통해 작동하지 않으므로 사용하지 않는 것이 좋습니다.

해당 테스트는 수동으로 수행하지 않아도 됩니다. 설명했던 대기 시간 테스트를 자동화하는 PowerShell 프로시저 가용성 영역 대기 시간 테스트를 찾을 수 있습니다.

가용성 영역의 VM SKU 측정값 및 가용성에 따라, 다음과 같은 사항을 결정해야 합니다.

  • 데이터베이스 계층에 적합한 영역을 정의합니다.
  • 영역 내부 및 영역 간 네트워크 대기 시간 차이에 따라, 1개, 2개 또는 3개의 모든 영역에서 활성 SAP 애플리케이션 계층을 배포할 것인지를 결정합니다.
  • 애플리케이션 관점에서 액티브/패시브 구성을 배포할지 또는 액티브/액티브 구성을 배포할지를 결정합니다. (이러한 구성은 이 문서의 뒷부분에서 설명합니다.)

Important

수행하는 측정 및 의사 결정은 이러한 측정을 수행할 때 사용한 Azure 구독에 대해 유효합니다. 다른 Azure 구독을 사용하는 경우 열거된 영역의 매핑이 다른 Azure 구독과 다를 수 있습니다. 따라서 측정을 반복하거나 도구 Avzone-Mapping 스크립트를 통해 이전 구독에 대한 새 구독의 매핑을 찾아야 합니다.

Important

앞에서 설명한 측정값은 가용성 영역 지원하는 모든 Azure 지역에서 서로 다른 결과를 제공할 것으로 예상됩니다. 네트워크 대기 시간에 대한 요구 사항은 같더라도, 영역 간 네트워크 대기 시간이 다를 수 있으므로 Azure 지역마다 다른 배포 전략을 채택해야 할 수 있습니다. 일부 Azure 지역에서는 3개의 다른 영역 간 네트워크 대기 시간이 크게 다를 수 있습니다. 반면에 다른 지역에서는 3개의 다른 영역 간 네트워크 대기 시간이 좀 더 균일할 수 있습니다. 항상 1~2밀리초 사이의 네트워크 대기 시간이 나타난다는 주장은 맞지 않습니다. Azure 지역의 가용성 영역 간 네트워크 대기 시간은 일반화할 수 없습니다.

액티브/액티브 배포

해당 배포 아키텍처는 두세 개의 영역 간에 활성 SAP 애플리케이션 서버를 배포한다는 점에서 활성/활성으로 불립니다. 큐에 넣기 복제를 사용하는 SAP Central Services 인스턴스는 두 영역 간에 배포됩니다. SAP Central Service와 동일한 영역에 배포되는 데이터베이스 계층도 마찬가지입니다. 이 구성을 고려할 때 워크로드에 허용되는 영역 간 네트워크 대기 시간을 제공하는 지역에서 두 가용성 영역 찾아야 합니다. 또한 선택한 영역 내의 네트워크 대기 시간과 영역 간 네트워크 대기 시간 사이의 델타가 워크로드에 허용되는지 확인하려고 합니다.

두 영역에 걸친 액티브/액티브 배포의 단순화된 스키마는 다음과 같을 수 있습니다.

액티브/액티브 영역 배포

이 구성에 대해 다음과 같은 고려 사항이 적용됩니다.

  • Azure 근접 배치 그룹을 사용하지 않으면 가용성 집합을 Azure 가용성 영역에 배포할 수 없으므로 Azure 가용성 영역을 모든 VM의 장애 도메인으로 취급합니다.
  • 데이터베이스 계층 및 중앙 서비스에 대한 영역 배포를 결합하지만 애플리케이션 계층에 Azure 가용성 집합을 사용하려는 경우 SAP 애플리케이션과의 네트워크 대기 시간을 최적화하기 위해 Azure 근접 배치 그룹 문서에 설명된 대로 Azure 근접 그룹을 사용해야 합니다.
  • SAP Central Services의 장애 조치(failover) 클러스터 및 데이터베이스 계층의 부하 분산 장치의 경우 표준 SKU Azure Load Balancer를 사용해야 합니다. 기본 Load Balancer는 영역 간에 작동하지 않습니다.
  • 원하는 영역 보호를 얻으려면 ExpressRoute 게이트웨이, VPN Gateway 및 표준 공용 IP 주소의 영역 버전을 배포해야 합니다.
  • SAP 시스템을 호스트하기 위해 배포한 Azure Virtual Network 및 해당 서브넷은 영역에 걸쳐 확장됩니다. 각 영역마다 별도의 가상 네트워크와 서브넷이 필요하지 않습니다.
  • 배포하는 모든 가상 머신에 대해 Azure Managed Disks를 사용해야 합니다. 영역 배포에서 관리되지 않는 디스크는 사용할 수 없습니다.
  • Azure Premium SSD v2, Ultra SSD 스토리지 또는 Azure NetApp Files는 영역 간에 동기 스토리지 복제를 지원하지 않습니다. 데이터베이스 배포의 경우 데이터베이스 메서드를 사용하여 영역 간에 데이터를 복제합니다.
  • 가용성 영역 걸쳐 동기 영역 복제를 지원하는 프리미엄 SSD v1은 SAP 데이터베이스 워크로드로 테스트되지 않았습니다. 따라서 Azure Premium SSD v1의 영역 동기 복제는 SAP 데이터베이스 워크로드에 지원되지 않는 것으로 간주되어야 합니다.
  • Azure Premium Files를 기반으로 하는 SMB 및 NFS 공유의 경우 동기 복제를 사용하는 영역 중복성이 제공됩니다. 배포하려는 지역에서 Azure Premium Files용 ZRS를 사용할 수 있는지 확인하려면 이 문서를 확인합니다. 영역 복제된 NFS 및 SMB 공유의 사용은 SAP 애플리케이션 계층 배포 및 NetWeaver 또는 S/4HANA 중앙 서비스용 고가용성 장애 조치 클러스터에서 완전히 지원됩니다. 이러한 경우를 다루는 문서는 다음과 같습니다.
  • 세 번째 영역은 SUSE Linux Pacemaker 클러스터를 빌드하고 SBD 디바이스를 Azure Fencing 에이전트 대신 사용하는 경우에 SBD 디바이스를 호스트하는 데 사용됩니다. 또는 더 많은 애플리케이션 인스턴스의 경우도 해당됩니다.
  • 중요한 비즈니스 프로세스에 대한 런타임 일관성을 달성하기 위해 SAP 일괄 처리 서버 그룹, SAP 로그온 그룹 또는 RFC 그룹을 사용하여 특정 일괄 처리 작업 및 사용자를 활성 데이터베이스 인스턴스와 함께 영역 내의 애플리케이션 인스턴스로 보낼 수 있습니다. 그러나 영역 장애 조치(failover) 프로세스에서는 이러한 그룹을 활성 DB VM이 있는 영역 내에 있는 VM에서 실행되는 인스턴스로 수동으로 이동해야 합니다.
  • 각 영역에서 유휴 대화 상자 인스턴스를 배포할 수 있습니다.

Important

이 활성/활성 시나리오에서는 영역 간 트래픽에 대한 요금이 적용됩니다. Bandwidth 가격 세부 정보 문서를 확인하세요. SAP 애플리케이션 계층과 SAP 데이터베이스 계층 간의 데이터 전송은 매우 집약적입니다. 따라서 활성/활성 시나리오는 비용에 영향을 미칠 수 있습니다.

액티브/패시브 배포

SAP 비즈니스 프로세스의 런타임에서 잠재적 델타를 완화하는 구성을 찾을 수 없거나 짧은 거리 재해 복구 구성을 배포하려는 경우 SAP 애플리케이션 계층 관점에서 활성/수동 문자가 있는 아키텍처를 배포할 수 있습니다. 전체 애플리케이션 계층을 배포하고 활성 데이터베이스 인스턴스와 SAP Central Services 인스턴스를 모두 실행하려고 하는 영역인 활성 영역을 정의합니다. 이러한 구성을 사용하면 작업이 활성 데이터베이스 인스턴스를 사용하여 영역에서 실행되는지 여부에 따라 비즈니스 트랜잭션 및 일괄 처리 작업에서 극단적인 런타임 변형이 없는지 확인해야 합니다.

이 아키텍처의 기본 레이아웃은 다음과 같습니다.

액티브/패시브 영역 배포

이 구성에 대해 다음과 같은 고려 사항이 적용됩니다.

  • Azure 가용성 영역에서 가용성 집합을 배포할 수 없습니다. 완화하려면 SAP 애플리케이션을 사용한 최적의 네트워크 대기 시간을 위해 Azure 근접 배치 그룹 문서에 설명된 대로 Azure 근접 배치 그룹을 사용할 수 있습니다.
  • 이 아키텍처를 사용하는 경우 상태를 면밀히 모니터링하고 배포된 애플리케이션 계층과 동일한 영역에 활성 데이터베이스 인스턴스 및 SAP Central Services 인스턴스를 유지해야 합니다. SAP Central Service 또는 데이터베이스 인스턴스의 장애 조치(failover)가 있는 경우 SAP 애플리케이션 계층이 가능한 한 빨리 배포된 영역으로 수동으로 장애 복구(failback)할 수 있는지 확인하려고 합니다.
  • SAP Central Services의 장애 조치(failover) 클러스터 및 데이터베이스 계층의 부하 분산 장치의 경우 표준 SKU Azure Load Balancer를 사용해야 합니다. 기본 Load Balancer는 영역 간에 작동하지 않습니다.
  • 원하는 영역 보호를 얻으려면 ExpressRoute 게이트웨이, VPN Gateway 및 표준 공용 IP 주소의 영역 버전을 배포해야 합니다.
  • SAP 시스템을 호스트하기 위해 배포한 Azure Virtual Network 및 해당 서브넷은 영역에 걸쳐 확장됩니다. 각 영역에 대해 별도의 가상 네트워크가 필요하지 않습니다.
  • 배포하는 모든 가상 머신에 대해 Azure Managed Disks를 사용해야 합니다. 영역 배포에서 관리되지 않는 디스크는 사용할 수 없습니다.
  • Azure Premium SSD v2, Ultra SSD 스토리지 또는 Azure NetApp Files는 영역 간에 동기 스토리지 복제를 지원하지 않습니다. 데이터베이스 배포의 경우 데이터베이스 메서드를 사용하여 영역 간에 데이터를 복제합니다.
  • 가용성 영역 걸쳐 동기 영역 복제를 지원하는 프리미엄 SSD v1은 SAP 데이터베이스 워크로드로 테스트되지 않았습니다. 따라서 Azure Premium SSD v1의 구성 가능한 영역 동기 복제는 SAP 데이터베이스 워크로드에 지원되지 않는 것으로 간주되어야 합니다.
  • Azure Premium Files를 기반으로 하는 SMB 및 NFS 공유의 경우 동기 복제를 사용하는 영역 중복성이 제공됩니다. 배포하려는 지역에서 Azure Premium Files용 ZRS를 사용할 수 있는지 확인하려면 이 문서를 확인합니다. 영역 복제된 NFS 및 SMB 공유의 사용은 SAP 애플리케이션 계층 배포 및 NetWeaver 또는 S/4HANA 중앙 서비스용 고가용성 장애 조치 클러스터에서 완전히 지원됩니다. 이러한 경우를 다루는 문서는 다음과 같습니다.
  • 세 번째 영역은 SUSE Linux Pacemaker 클러스터를 빌드하고 SBD 디바이스를 Azure Fencing 에이전트 대신 사용하는 경우에 SBD 디바이스를 호스트하는 데 사용됩니다. 또는 추가적인 애플리케이션 인스턴스에 사용됩니다.
  • 영역 오류의 경우 애플리케이션 리소스를 시작할 수 있도록 수동 영역에 휴면 VM을 배포해야 합니다(데이터베이스 관점에서). 또 다른 가능성은 Azure Site Recovery를 사용하는 것일 수 있습니다. 이 기능은 영역 간에 활성 VM을 휴면 VM으로 복제할 수 있습니다.
  • 영역 중단이 발생할 경우 두 번째 영역에서 SAP 애플리케이션 계층을 자동으로 시작하도록 하는 자동화 기능에 투자해야 합니다.

높은 가용성 및 재해 복구 구성

Microsoft는 Azure 지역의 다른 Azure 가용성 영역을 호스트하는 시설 간의 지리적 거리에 대한 정보를 공유하지 않습니다. 그러나 일부 고객은 RPO(복구 지점 목표)를 0으로 약속하는 결합된 HA 및 DR 구성(짧은 거리 DR)에 영역을 사용하고 있습니다. RPO가 없다는 것은 재해 복구의 경우에도 커밋된 데이터베이스 트랜잭션을 손실하지 않게 된다는 것을 의미합니다.

참고 항목

가용성 영역 소거리 DR 솔루션으로 사용하는 경우, 전력 인프라에 대한 무겁고 광범위한 손상을 포함하여 전 세계 일각에서 광범위한 피해를 초래하는 자연 재해가 발생했음을 염두에 두어야 합니다. 다양한 영역 사이의 거리가 항상 그렇게 큰 자연 재해를 보상하기에 충분히 크지 않을 수 있습니다.

다음은 이러한 구성의 작동 방식 예제입니다.

영역의 결합된 고가용성 DR

이 구성에 대해 다음과 같은 고려 사항이 적용됩니다.

  • 가용성 영역을 호스팅하는 시설 간에 상당한 거리가 있다고 가정합니다. 또는 특정 Azure 지역 내에 있어야 합니다. Azure 가용성 영역에서 가용성 집합을 배포할 수 없습니다. 이를 보완하고자 SAP 애플리케이션을 이용해 네트워크 대기 시간을 최적화하기 위한 Azure 근접 배치 그룹 문서에서 설명한 대로 Azure 근접 배치 그룹을 사용할 수 있습니다.
  • 이 아키텍처를 사용하는 경우 상태를 면밀히 모니터링하고 배포된 애플리케이션 계층과 동일한 영역에 활성 데이터베이스 인스턴스 및 SAP Central Services 인스턴스를 유지하려고 합니다. SAP Central Service 또는 데이터베이스 인스턴스의 장애 조치(failover)가 있는 경우 SAP 애플리케이션 계층이 가능한 한 빨리 배포된 영역으로 수동으로 장애 복구(failback)할 수 있는지 확인하려고 합니다.
  • 프로덕션 애플리케이션 인스턴스를 활성 QA 애플리케이션 인스턴스를 실행하는 VM에 미리 설치해야 합니다.
  • 영역 오류 발생 시 QA 애플리케이션 인스턴스를 종료하고, 대신 프로덕션 인스턴스를 시작합니다. 이렇게 하려면 애플리케이션 인스턴스의 가상 이름을 사용해야 합니다.
  • SAP Central Services의 장애 조치(failover) 클러스터 및 데이터베이스 계층의 부하 분산 장치의 경우 표준 SKU Azure Load Balancer를 사용해야 합니다. 기본 Load Balancer는 영역 간에 작동하지 않습니다.
  • 원하는 영역 보호를 얻으려면 ExpressRoute 게이트웨이, VPN Gateway 및 표준 공용 IP 주소의 영역 버전을 배포해야 합니다.
  • SAP 시스템을 호스트하기 위해 배포한 Azure Virtual Network 및 해당 서브넷은 영역에 걸쳐 확장됩니다. 각 영역에 대해 별도의 가상 네트워크가 필요하지 않습니다.
  • 배포하는 모든 가상 머신에 대해 Azure Managed Disks를 사용해야 합니다. 영역 배포에서 관리되지 않는 디스크는 사용할 수 없습니다.
  • Azure Premium SSD v2, Ultra SSD 스토리지 또는 Azure NetApp Files는 영역 간에 동기 스토리지 복제를 지원하지 않습니다. 데이터베이스 배포의 경우 데이터베이스 메서드를 사용하여 영역 간에 데이터를 복제합니다.
  • 가용성 영역 걸쳐 동기 영역 복제를 지원하는 프리미엄 SSD v1은 SAP 데이터베이스 워크로드로 테스트되지 않았습니다. 따라서 Azure Premium SSD v1의 구성 가능한 영역 동기 복제는 SAP 데이터베이스 워크로드에 지원되지 않는 것으로 간주되어야 합니다.
  • Azure Premium Files를 기반으로 하는 SMB 및 NFS 공유의 경우 동기 복제를 사용하는 영역 중복성이 제공됩니다. 배포하려는 지역에서 Azure Premium Files용 ZRS를 사용할 수 있는지 확인하려면 이 문서를 확인합니다. 영역 복제된 NFS 및 SMB 공유의 사용은 SAP 애플리케이션 계층 배포 및 NetWeaver 또는 S/4HANA 중앙 서비스용 고가용성 장애 조치 클러스터에서 완전히 지원됩니다. 이러한 경우를 다루는 문서는 다음과 같습니다.
  • 세 번째 영역은 SUSE Linux Pacemaker 클러스터를 빌드하고 SBD 디바이스를 Azure Fencing 에이전트 대신 사용하는 경우에 SBD 디바이스를 호스트하는 데 사용됩니다.

다음 단계

Azure 가용성 영역에 걸쳐 배포하기 위한 다음 단계는 다음과 같습니다.