SAP 마이그레이션을 위한 비즈니스 연속성 및 재해 복구

이 문서는 BCDR에 대한 Azure 랜딩 존 디자인 영역의 고려 사항 및 권장 사항을 기반으로 합니다. 이 문서에서는 SAP 플랫폼을 지원하는 랜딩 존에 대한 고유한 제약 조건에 대해 설명합니다. SAP는 중요 업무용 플랫폼이므로 다른 중요 업무용 지침 도 디자인에 통합해야 합니다.

시나리오 및 범위

온-프레미스 BCDR(비즈니스 연속성 및 재해 복구) 시나리오를 해결하는 원칙을 아키텍처에 통합합니다. 이러한 원칙은 Azure에도 적용됩니다. 그러나 Azure는 호스트 오류를 보상하기 위해 온-프레미스 환경보다 더 많은 하드웨어 용량을 가질 수 있습니다. 가장 큰 Azure VM(가상 머신)조차도 자동으로 복구하려면 다른 서버에서 다시 시작하도록 구성할 수 있습니다. 온-프레미스 배포와 동일한 조건을 사용하도록 Azure 배포를 설정합니다. 자동 장애 조치(failover) 클러스터 구성을 사용하여 온-프레미스 시스템 또는 운영 체제 미설치 하드웨어를 배포하는 경우 Azure에서 동일한 방식으로 배포합니다. 조직의 가장 중요한 비즈니스 프로세스를 실행하는 SAP 애플리케이션에는 다음이 필요합니다.

• 서비스 및 비즈니스 프로세스 가용성.

• 오류 시나리오 또는 재해 시나리오에 대한 RTO(복구 시간 목표)입니다.

• 실패 시나리오에 대한 RPO(복구 지점 목표)입니다.

• 운영 및 수명 주기 관리 작업 및 실패 시나리오 중에 실행되는 기술. 이러한 관리 작업에는 게스트 운영 체제 및 데이터베이스 관리 시스템 패치, 복제, SAP 시스템 새로 고침이 포함됩니다.

팁

초기에 SAP 환경의 각 아키타입에 대한 HADR(고가용성 및 재해 복구) 솔루션을 결정합니다. 솔루션이 모든 SAP 구성 요소를 포함하는지 확인합니다.

하나 이상의 환경에서 Azure에서 HADR 솔루션을 일찍 구성하고 활성 상태로 유지합니다. 그러면 팀은 기존 기술과 다를 수 있는 솔루션의 기술에 대한 경험을 얻을 수 있습니다. 표준 SOP(운영 절차)를 개발하고 발전시킬 수 있도록 HADR을 조기에 구성합니다.

시스템이 라이브 상태가 되는 즉시 프로덕션 워크로드에 대한 완전한 고가용성, 재해 복구 및 백업 보호를 계획합니다.

이 문서에서는 엔터프라이즈 규모 SAP 시나리오에 대한 BCDR의 다음 측면을 다룹니다.

• Azure 지역 내의 고가용성

• 백업 및 복원 고려 사항

• 지역 간 재해 복구와 지역 간 재해 복구를 결정하는 기준

Azure 지역 내의 고가용성

다음 섹션에서는 SAP 엔터프라이즈 시나리오에 대한 Azure 지역 내의 고가용성을 위한 디자인 고려 사항 및 권장 사항을 제공합니다.

고가용성을 위한 디자인 고려 사항

고가용성을 구현하는 경우 목표는 다음과 같은 SAP 소프트웨어의 단일 실패 지점에 대한 가용성을 제공하는 것입니다.

• 데이터베이스 관리 시스템.

• SAP ABAP(Advanced Business Application Programming), ABAP SAP Central Services(ASCS) 및 SCS(SAP Central Services)와 같은 애플리케이션의 단일 실패 지점 고가용성 예제에는 SAP NetWeaver 및 SAP S/4HANA 아키텍처가 포함됩니다.

• SAP Web Dispatcher와 같은 기타 도구.

다른 시나리오의 경우 인프라 오류 또는 소프트웨어 오류에 대한 가용성을 제한하지 마세요. 필요한 모든 수명 주기 관리 작업에 가용성을 적용합니다. 예를 들어 VM, DBMS(데이터베이스 관리 시스템) 및 SAP 소프트웨어에서 OS를 패치할 수 있습니다. 계획된 가동 중지 시간 및 수명 주기 관리 작업 중에 발생할 수 있는 중단을 최소화하려면 계획되지 않은 서비스 중단으로부터 시스템을 보호하는 일반적인 도구를 사용합니다.

SAP 및 SAP 데이터베이스는 자동 장애 조치(failover) 클러스터를 지원합니다. Windows에서 Windows Server 2022 장애 조치(failover) 클러스터링 기능은 장애 조치(failover)를 지원합니다. Linux에서 Linux Pacemaker 또는 SIOS Protection Suite 및 Veritas InfoScale과 같은 파트너 도구는 장애 조치(failover)를 지원합니다. Azure에서는 자체 데이터 센터에서 하위 집합 고가용성 구성만 배포할 수 있습니다.

자세한 내용은 Azure VM의 SAP 워크로드에 대해 지원되는 시나리오 및 SAP HANA 대규모 인스턴스에 대해 지원되는 시나리오를 참조하세요.

DBMS 계층의 경우 일반적인 아키텍처 패턴은 주 VM 및 보조 VM에서 사용하는 것과는 다른 스토리지 스택을 사용하여 동시에 데이터베이스를 복제하는 것입니다. Azure는 기본 VM 및 보조 VM이 DBMS 데이터에 대한 스토리지를 공유하는 아키텍처를 지원하지 않습니다. 또한 Azure는 트랜잭션 로그 또는 다시 실행 로그를 지원하지 않습니다. 지침 원칙은 NFS(네트워크 파일 시스템) 공유를 기반으로 하는 경우에도 2개의 독립 스토리지 스택을 사용하는 것입니다. 이러한 제한 사항은 온-프레미스 솔루션이 아닌 Azure 솔루션에만 적용됩니다.

Azure는 NFS 및 서버 메시지 블록 공유를 지원하므로 다른 옵션을 제공합니다. ASCS 및 SCS 구성 요소 및 특정 고가용성 시나리오를 위해 Windows에서 Azure 공유 디스크를 사용할 수 있습니다. SAP 애플리케이션 계층 구성 요소 및 DBMS 계층에 대해 장애 조치(failover) 클러스터를 별도로 설정합니다. Azure는 SAP 애플리케이션 계층 구성 요소와 DBMS 계층을 하나의 장애 조치(failover) 클러스터로 결합하는 고가용성 아키텍처를 지원하지 않습니다.

SAP 애플리케이션 계층 구성 요소 및 DBMS 계층에 대한 대부분의 장애 조치(failover) 클러스터에는 장애 조치(failover) 클러스터에 대한 가상 IP 주소가 필요합니다. 일반적인 예외는 가상 IP 주소가 필요하지 않은 Oracle Data Guard를 사용하는 경우입니다. Azure Load Balancer는 다른 모든 경우에 대한 가상 IP 주소를 처리해야 합니다. 각 클러스터 구성에 대해 하나의 부하 분산 장치를 사용할 수 있습니다. 표준 버전의 부하 분산 장치를 사용하는 것이 좋습니다. 자세한 내용은 SAP 고가용성 시나리오에서 표준 Azure Load Balancer를 사용하여 VM에 대한 공용 엔드포인트 연결을 참조하세요.

자세한 내용은 SAP NetWeaver에 대한 고가용성 아키텍처 및 시나리오를 참조 하세요.

다음 표에서는 다양한 고가용성 배포 옵션에 대한 플랫폼 수준 SLA(서비스 수준 계약)를 보여 줍니다. 관리되는 서비스를 제공하는 파트너는 애플리케이션 수준 SLA도 제공합니다.

계층	고가용성 시나리오	플랫폼 SLA
1	가용성 영역	99.99%
2	가용성 집합	99.95%
3	단일 VM(자가 복구)	99.90%

Azure 가용성 집합과 가용성 영역 비교

고가용성 인프라를 배포하기 전에 선택한 지역에 따라 Azure 가용성 집합 또는 가용성 영역을 사용하여 배포할지 여부를 결정합니다. 가용성 집합을 사용하여 배포하는 VM의 주요 차이점은 다음과 같습니다.

• VM은 서로 다른 가용성 영역에 분산되지 않습니다.

• 집합에 배포하는 첫 번째 VM이 호스트를 정의하기 때문에 단일 가용성 집합을 통해 배포할 수 있는 VM 유형이 제한됩니다. 예를 들어 M 시리즈 VM과 E 시리즈 VM을 하나의 가용성 집합으로 결합할 수 없습니다.

여러 가용성 영역에 고가용성 아키텍처를 배포하는 경우 VM에 대해 더 높은 SLA를 가질 수 있습니다. 자세한 내용은 Azure VM SLA를 참조 하세요. Azure 지역에 따라 VM 간의 네트워크 트래픽에서 서로 다른 네트워크 대기 시간 조건을 검색할 수 있습니다. 자세한 내용은 Azure 가용성 영역을 사용하여 SAP 워크로드 구성을 참조하세요.

영역 배포 방법을 선택하는 경우 선택한 Azure 지역에 대한 영역 간 대기 시간이 성능 및 아키텍처 디자인 선택에 미치는 영향을 고려합니다. 애플리케이션 서버와 데이터베이스 간의 대기 시간과 두 데이터베이스 노드 간의 대기 시간을 고려합니다.

애플리케이션 서버가 동일한 가용성 영역의 데이터베이스에 연결해야 하는 애플리케이션 서버 계층에 대해 활성/수동 영역 배포를 사용하는 경우 자동화를 구성하고 데이터베이스 장애 조치(failover)가 발생하는 경우 빠르고 자동화된 복구를 사용하도록 SOP를 만듭니다.

SAP 솔루션에서 가용성 영역을 사용하는 경우 영역 중복성을 위해 SAP 환경의 다른 모든 Azure 서비스 및 인프라 구성 요소도 설계하여 진정한 영역 중복성을 달성할 수 있습니다. 고려해야 할 서비스 및 구성 요소의 예로는 Azure ExpressRoute 게이트웨이, Load Balancer, Azure Files, Azure NetApp Files, 역방향 프록시, 방화벽, 바이러스 백신 서비스 및 백업 인프라가 있습니다.

고가용성을 위한 디자인 권장 사항

• Azure는 애플리케이션의 인프라 SLA를 충족하는 데 도움이 되는 몇 가지 옵션을 제공합니다. 중앙 서비스, 애플리케이션 서버 및 데이터베이스의 세 가지 SAP 구성 요소 모두에 대해 동일한 옵션을 선택해야 합니다. VM, 가용성 집합 및 가용성 영역에 대한 SLA에 대한 자세한 내용은 온라인 서비스 SLA를 참조하세요.

• 가용성 집합에 VM을 배포할 때 장애 도메인 및 업데이트 도메인과의 정렬을 통해 VM이 동일한 호스트 하드웨어에 있지 않도록 하여 하드웨어 오류에 대한 보호를 제공합니다. 가용성 영역을 통해 VM을 배포하고 다른 영역을 사용하는 경우 여러 물리적 위치에서 VM을 만듭니다. 이 구성은 영역 전체의 데이터 센터에 영향을 주는 전원, 냉각 또는 네트워킹 문제에 대한 추가 보호를 제공합니다. 그러나 근접 배치 그룹을 사용하지 않는 한 Azure 가용성 영역 내에 Azure 가용성 집합을 배포할 수 없습니다.

  영역 배포 방법을 선택하면 SAP DBMS, 중앙 서비스 및 애플리케이션 레이어가 서로 다른 가용성 영역에서 실행됩니다. 그러나 각 가용성 영역에는 여러 애플리케이션 서버가 있는 가능성이 높습니다. 이 시나리오에서 각 영역의 애플리케이션 서버는 장애 도메인 및 업데이트 도메인의 이점을 자동으로 활용하지 않습니다. 가용성 집합을 사용하여 이러한 이점을 얻을 수 있습니다. 자세한 내용은 SAP를 사용한 최적의 네트워크 대기 시간에 대한 Azure 근접 배치 그룹을 참조하세요.

• 가용성 집합을 만들 때 최대 장애 도메인 수를 사용하고 사용 가능한 도메인을 업데이트합니다. 예를 들어 하나의 가용성 집합에 두 개 이상의 VM을 배포하는 경우 최대 장애 도메인 수(3개)를 사용합니다. 또한 충분한 업데이트 도메인을 사용하여 Azure 계획된 유지 관리 외에도 잠재적인 물리적 하드웨어 오류, 네트워크 중단 또는 전원 중단의 영향을 제한합니다. 기본 장애 도메인 수는 2개이며 나중에 온라인으로 변경할 수 없습니다.

• 가용성 집합 배포에서 SAP 시스템의 각 구성 요소는 자체 가용성 집합에 있어야 합니다. SAP 중앙 서비스, 데이터베이스, 애플리케이션 VM은 자체 가용성 집합에 있어야 합니다.

• 가용성 집합 배포에서 Azure 근접 배치 그룹을 사용하는 경우 세 개의 SAP 구성 요소(중앙 서비스, 애플리케이션 서버 및 데이터베이스)가 모두 동일한 근접 배치 그룹에 있는지 확인합니다.

• 근접 배치 그룹을 사용하는 경우 각 SAP SID(시스템 식별)에 대해 하나를 사용합니다. 그룹은 가용성 영역 또는 Azure 지역에 걸쳐 있지 않습니다.

• 가용성 영역 배포에서 Azure 근접 배치 그룹을 사용하는 경우 두 SAP 구성 요소(중앙 서비스 및 애플리케이션 서버)가 동일한 근접 배치 그룹에 있는지 확인합니다. 두 영역에서 데이터베이스 VM은 더 이상 근접 배치 그룹의 일부가 아닙니다. 각 영역에 대한 근접 배치 그룹은 SAP ASCS 및 SCS 인스턴스를 실행하는 VM의 배포로 범위가 지정됩니다. 이 구성의 장점은 VM 크기를 조정할 수 있는 유연성이 더 있다는 것입니다. 또한 SAP 시스템의 DBMS 계층 또는 애플리케이션 계층에서 새 VM 유형으로 쉽게 전환할 수 있습니다.

• Azure는 단일 Linux Pacemaker 클러스터에서 ASCS 및 데이터베이스 고가용성 결합을 지원하지 않습니다. 개별 클러스터로 분리합니다. VM 쌍에서 최대 5개의 여러 중앙 서비스 클러스터를 결합할 수 있습니다.

• ASCS 및 데이터베이스 클러스터 앞에서 표준 Load Balancer 사용합니다.

• Azure Premium SSD에서 모든 프로덕션 시스템을 실행하고 Azure NetApp Files 또는 Azure Ultra Disk Storage를 사용합니다. 최소한 성능을 향상시키고 최상의 SLA를 얻을 수 있도록 OS 디스크가 프리미엄 계층에 있는지 확인합니다.

• 가용성 집합 또는 가용성 영역에서 고가용성 쌍에 두 VM을 배포합니다. 이러한 VM의 크기가 동일하고 스토리지 구성이 동일한지 확인합니다.

• 네이티브 데이터베이스 복제 기술을 사용하여 데이터베이스를 고가용성 쌍으로 동기화합니다.

• 다음 서비스 중 하나를 사용하여 OS에 따라 SAP 중앙 서비스 클러스터를 실행합니다.

  • SUSE Linux Enterprise Server Pacemaker 클러스터는 Azure 펜스 에이전트 및 최대 3개의 노드 격리 디바이스를 지원합니다.

  • Red Hat Enterprise Linux Pacemaker 클러스터는 Azure 펜스 에이전트를 지원하며 노드 격리 디바이스를 지원하지 않습니다.

  • Windows 클러스터.

  • SAP 인증 비 Microsoft 클러스터 소프트웨어.

• 중앙 서비스 및 데이터베이스 클러스터에 대한 설명서에서 권장되는 클러스터 시간 제한 매개 변수를 설정합니다.

SAP 워크로드용 스토리지

• SAP 워크로드에서 복원력을 위해 디자인할 때 적절한 스토리지 옵션을 선택합니다. SAP 워크로드에 대한 적절한 Azure Storage 디자인은 대기 시간을 최소화하고 처리량을 최대화할 수 있습니다. 구현과 다음 지침이 Azure의 SAP 구현에 대한 아키텍처 결정을 내리는 데 어떻게 도움이 되는지 고려합니다. 자세한 내용은 SAP 워크로드에 대한 Azure Storage 유형을 참조 하세요.

• AZURE에서 SAP HANA는 SAP 인증 스토리지 유형에서만 실행해야 합니다. 특정 디스크 구성에서 특정 볼륨을 실행해야 합니다. 예를 들어 구성은 Write Accelerator를 사용하도록 설정하거나 프리미엄 SSD 스토리지를 사용할 수 있습니다. 또한 스토리지에서 실행되는 파일 시스템이 컴퓨터에서 실행되는 DBMS와 호환되는지 확인해야 합니다. 자세한 내용은 SAP HANA에 대한 스토리지 구성을 참조하세요.

• VM에 연결된 Azure 관리형 데이터 디스크 외에도 다양한 Azure 네이티브 공유 스토리지 솔루션은 Azure에서 SAP 애플리케이션을 실행합니다. Azure Site Recovery는 Azure에서 사용할 수 있는 일부 스토리지 서비스를 지원하지 않으므로 고가용성 구성이 다를 수 있습니다. SAP 워크로드에 다음 스토리지 유형을 사용합니다.

  스토리지 유형	고가용성 구성 지원
  Azure 공유 디스크(LRS(로컬 중복 스토리지) 또는 ZRS(영역 중복 스토리지))	Windows Server 2022 장애 조치(failover) 클러스터. 구성 세부 정보는 Windows Server 2022 장애 조치(failover) 클러스터링을 사용하여 SAP 고가용성 디자인을 참조 하세요.
  Azure Files의 NFS(LRS 또는 ZRS)	Linux 환경의 Pacemaker 기반 클러스터입니다. 다양한 지역에서 NFS의 가용성을 확인해야 합니다.
  Azure NetApp Files의 NFS	Linux 환경의 Pacemaker 기반 클러스터입니다. 자세한 내용은 SAP VM용 Azure NetApp Files를 참조하세요.
  Azure Files의 SMB(LRS 또는 ZRS)	Windows Server 2022 장애 조치(failover) 클러스터. 구성 세부 정보는 Azure Files SMB를 사용하여 고가용성 SAP NetWeaver 설치를 참조하세요.
  Azure NetApp Files의 SMB	Windows Server 2022 장애 조치(failover) 클러스터. 구성 세부 정보는 SAP 애플리케이션용 Azure NetApp Files(SMB)를 사용하는 SAP NetWeaver의 고가용성을 참조 하세요.

• Azure 네이티브 공유 스토리지 서비스 대신 기존 NFS 클러스터(분산 복제된 블록 디바이스 복제 기반), GlusterFS 또는 저장소 공간 Direct가 있는 클러스터 공유 볼륨을 대체 공유 스토리지 솔루션으로 사용하여 Azure에서 SAP 워크로드를 실행할 수 있습니다. 이러한 선택은 대상 Azure 지역에서 Azure 네이티브 공유 스토리지 서비스를 사용할 수 없거나 대상 아키텍처를 지원하지 않는 경우에 특히 유용합니다. 스토리지 서비스 가용성에 대한 자세한 내용은 지역별 Azure 제품을 참조하세요.

• Azure의 SAP 워크로드에 사용할 수 있는 스토리지 옵션에 대한 자세한 내용은 재해 복구를 설정하기 위한 스토리지 권장 사항 및 지침을 참조하세요.

백업 및 복원

다음 섹션에서는 SAP 시나리오의 백업 및 복원에 대한 디자인 고려 사항 및 권장 사항에 대해 설명합니다.

백업 및 복원은 일반적으로 프로덕션 SAP 워크로드에 적합한 고가용성 솔루션으로 간주되지 않지만 이 기술은 다른 이점을 제공합니다. SAP 애플리케이션을 사용하는 대부분의 회사는 백업의 장기 스토리지가 필요한 규정 준수 규정을 따라야 합니다. 다른 시나리오에서는 복원할 수 있는 백업도 있어야 합니다. 이 지침에서는 이미 백업 및 복원을 설정하고 SAP 애플리케이션에 대한 모범 사례를 따른다고 가정합니다. 즉, 다음을 수행할 수 있습니다.

• RTO를 충족하는 시간 프레임에서 언제든지 프로덕션 데이터베이스에 대한 특정 시점 복원을 수행합니다. 특정 시점 복원은 일반적으로 DBMS 레이어 또는 SAP를 통해 데이터 삭제와 같은 운영자 오류로부터 보호합니다.

• 규정을 준수하기 위해 장기 백업을 보관하는 저장소를 유지합니다.

• 데이터베이스 백업을 사용하여 SAP 시스템을 복제하고 다른 서버 또는 VM에 대한 백업을 복원합니다.

• 데이터베이스 백업의 프로덕션 데이터베이스 데이터를 사용하여 비프로덕션 시스템을 새로 고칩니다.

• SAP 애플리케이션 서버 및 VM, 디스크 또는 VM 스냅샷을 백업합니다.

• 복제를 사용하도록 설정된 SAP HANA 시스템을 백업합니다.

• SAP HANA 데이터베이스 인스턴스 스냅샷을 백업합니다.

온-프레미스를 백업하고 복원하는 경우 이러한 기능을 Azure의 SAP 시스템에 가져와야 합니다. 현재 솔루션을 원하는 경우 백업 공급업체가 Azure 배포를 지원하는지 또는 Azure용 SaaS(Software as a Service) 솔루션이 있는지 확인합니다.

Azure는 VM 스냅샷을 만들고 스트리밍 SQL Server 및 SAP HANA 백업을 관리하는 Azure Backup이라는 백업 SaaS 서비스를 제공합니다. Azure NetApp Files를 사용하여 SAP HANA 데이터베이스를 저장하는 경우 HANA 일치 스토리지 스냅샷을 기반으로 백업을 수행할 수 있습니다.

Azure Backup을 사용하여 SAP HSR(HANA 시스템 복제)을 사용하도록 설정된 데이터베이스를 백업할 수도 있습니다. Azure Backup은 장애 조치(failover)가 발생할 때 자동으로 백업을 관리하고 수동 개입이 필요하지 않습니다. 또한 Backup은 다음을 제공합니다.

• 전체 백업을 수정하지 않고 즉시 보호하므로 HANA 인스턴스 또는 HSR 설치 노드를 단일 HSR 컨테이너로 보호할 수 있습니다.

• 인스턴트 백업 및 즉시 복원의 이점입니다.

• SAP HANA용 Backint와 통합되는 HANA 일치 스냅샷 기반 접근 방식입니다. 전체 HANA 환경 및 모든 데이터베이스 크기에 대해 Backup을 단일 제품으로 사용할 수 있습니다.

자세한 내용은 복제를 사용하도록 설정된 SAP HANA 데이터베이스 시스템 및 SAP HANA 인스턴스 스냅샷 백업을 참조하세요.

백업 및 복원을 위한 디자인 권장 사항

• Azure Backup을 사용하여 SAP 애플리케이션 서버 및 중앙 서비스 VM을 백업할 수 있습니다.

• 최대 8TB의 HANA 배포에 SAP HANA 백업을 사용할 수 있습니다. 자세한 내용은 Azure VM에서 SAP HANA 데이터베이스의 백업에 대한 지원 매트릭스를 참조하세요.

• 인프라를 서비스 백업 솔루션으로 사용하는 경우 백업 인프라의 크기를 조정하여 모든 프로덕션 크기의 시스템을 동시에 백업하거나 실제 시나리오와 같이 예상 시간 프레임 내에 백업할 수 있도록 합니다. 네트워킹 및 보안과 같은 영역에 프로덕션 설정 또는 유사한 설정을 사용합니다.

• 백업 및 복구 시간을 테스트하여 재해 발생 후 모든 시스템을 동시에 복원하기 위한 RTO 요구 사항을 충족하는지 확인합니다.

• 특히 대규모 데이터베이스의 경우 Azure에서 온-프레미스 백업 인프라로 백업을 가져오지 않는 것이 가장 좋습니다. 이 방법은 ExpressRoute 회로에서 사용하는 대역폭의 양에 영향을 줄 수 있습니다.

• 부하 테스트는 성능 테스트 계획의 일부로 백업 및 복구 도구를 테스트합니다.

재해 복구

다음 섹션에서는 SAP 시나리오에서 재해 복구를 위한 디자인 고려 사항 및 권장 사항에 대해 설명합니다.

재해 복구를 위한 디자인 고려 사항

Azure 지역 맵에는 65개 이상의 Azure 지역이 포함되며 모든 지역이 동일한 서비스를 실행하는 것은 아닙니다. 더 큰 SAP 소프트웨어 배포, 특히 SAP HANA를 사용하는 배포의 경우 Azure M 시리즈 VM 또는 Mv2 시리즈 VM을 제공하는 Azure 지역을 찾습니다. 또한 Azure Storage에서는 서로 다른 지역을 쌍으로 연결하여 더 작은 스토리지 유형의 하위 집합을 다른 지역에 복제합니다. 자세한 내용은 Azure 쌍을 이루는 지역 개요를 참조하세요.

SAP 워크로드에 대해 Azure 지역을 페어링하는 주요 과제는 다음과 같습니다.

• 쌍이 항상 M 시리즈 또는 Mv2 시리즈 VM 서비스와 일치하지는 않습니다. SAP 시스템을 배포하는 많은 조직은 Azure 쌍을 이루는 지역을 사용하지 않습니다. 대신 필요한 VM 유형의 가용성에 따라 지역을 선택합니다.

• 쌍을 이루는 지역 간에 표준 스토리지를 복제할 수 있지만 표준 스토리지를 사용하여 데이터베이스 또는 가상 하드 디스크를 저장할 수는 없습니다. 사용하는 쌍을 이루는 지역 간에만 백업을 복제할 수 있습니다. 다른 모든 데이터의 경우 SQL Server Always On 또는 SAP HANA 시스템 복제와 같은 네이티브 DBMS 기능을 사용하여 복제를 실행합니다. SAP 애플리케이션 계층에 Site Recovery, 도구 등 rsync robocopy또는 기타 타사 소프트웨어의 조합을 사용합니다.

• 재해가 발생하면 Azure 지역의 영향을 받는 여러 고객이 쌍을 이루는 재해 복구 지역으로 장애 조치(failover)됩니다. 이러한 상황은 재해 복구 지역에서 휴면 VM을 발생시킬 리소스 경쟁으로 이어집니다. 해결 방법은 재해 복구 지역에서 비프로덕션 시스템을 실행하고 동일한 리소스를 사용하여 프로덕션 시스템의 재해 복구 복제본을 호스트하는 것입니다. 재해 복구 지역에서 Azure 인프라를 이중 용도로 사용하면 리소스 용량 제약 조건을 방지할 수 있습니다.

또 다른 중요한 고려 사항은 재해 지역에서 필요한 운영 용량을 보호하는 것입니다. 재해가 발생하는 경우 주 지역에서 정상 작업을 복구하는 동안에만 최소한의 IT 용량과 중요한 인적 자원으로 최소한의 시간 동안 SAP 애플리케이션을 실행해야 할 수 있습니다. 이 전략을 사용하려면 재해 복구 지역에서 사용할 수 있는 최소한의 IT 인프라가 필요합니다.

Azure 지역을 정의한 후 배포 패턴을 선택해야 합니다.

• 프로덕션 시스템을 주 지역에 배포하시겠습니까?

• 비프로덕션 SAP 시스템을 재해 복구 지역에 배포하시겠습니까?

• 모든 SAP 시스템을 주 지역으로 그룹화하는 아키텍처를 사용하시겠습니까? 이 구성은 재해 복구 지역이 재해 복구에만 사용되도록 합니다.

대부분의 조직은 SAP 시스템을 운영하기 위해 두 지역을 모두 사용합니다. 비즈니스 회귀 테스트 시스템으로 프로덕션 시스템의 전체 복사본을 실행하는 조직은 일반적으로 SAP 제품 라인의 비즈니스 회귀 테스트 시스템을 재해 복구 대상으로 사용할 계획입니다.

재해 복구 지역을 선택하는 경우 해당 지역에 대한 ExpressRoute 연결이 있어야 합니다. Azure에 연결하는 ExpressRoute 회로가 여러 개 있는 경우 해당 회로 중 하나 이상이 기본 Azure 지역에 연결해야 합니다. 다른 회로는 재해 복구 지역에 연결해야 합니다. 이러한 유형의 아키텍처는 다른 지리적 또는 지정학적 영역의 Azure 네트워크에 연결하고 재해가 Azure 지역 중 하나에 영향을 주는 경우 연결을 보호하는 데 도움이 됩니다.

일부 조직에서는 고가용성 및 재해 복구 아키텍처를 함께 사용합니다. 이 아키텍처는 동일한 Azure 지역에서 재해 복구를 사용하여 고가용성을 그룹화합니다. 그러나 재해 복구를 사용하여 고가용성을 그룹화하는 것은 바람직하지 않습니다. Azure 가용성 영역은 이 아키텍처를 지원합니다. 한 Azure 지역 내의 가용성 영역 간 거리는 두 Azure 지역 간의 거리만큼 크지 않으므로 자연 재해로 인해 발생하는 지역의 애플리케이션 서비스가 위태로워질 수 있습니다. SAP 애플리케이션 서버와 데이터베이스 서버 간의 대기 시간도 고려해야 합니다. SAP note 1100926 따르면 0.3ms 미만의 왕복 시간은 좋은 값이며 0.7ms보다 작거나 같은 시간은 보통 값입니다. 따라서 대기 시간이 긴 영역의 경우 SAP 애플리케이션 서버와 데이터베이스 서버가 항상 동일한 영역에서 실행되도록 하는 운영 절차를 갖습니다. 조직은 다음과 같은 이유로 이 아키텍처를 선택합니다.

• 규정 준수는 프로덕션 배포와 재해 복구 대상 간의 더 작은 거리를 지원하는 구성으로 충분합니다.

• 데이터 주권은 요인입니다.

• 지정학적 요인이 관련되어 있습니다.

• 영역 오류를 지원하는 저렴한 옵션이며, 때로는 큰 반경에 영향을 주는 자연 재해에 대한 보조 지역으로의 백업 전송과 결합됩니다.

재해 복구 지역을 선택할 때 고려해야 할 또 다른 요소는 재해 복구 사이트로 장애 조치(failover)하기 위한 RPO 및 RTO입니다. 프로덕션 지역과 재해 복구 지역 간의 거리가 클수록 네트워크 대기 시간이 높아질 수 있습니다. Azure 지역 간에 비동기적으로 복제하지만 네트워크 대기 시간은 복제할 수 있는 처리량과 RPO 대상에 영향을 줄 수 있습니다. RPO를 최소화하기 위해 결합된 고가용성 및 재해 복구 아키텍처를 사용할 수 있습니다. 그러나 이 구성은 대규모 자연 재해로 인한 잠재적으로 더 높은 위험을 초래합니다.

재해 복구를 위한 디자인 권장 사항

• 기본 가상 네트워크에 대한 클래스리스 CIDR(도메인 간 라우팅)이 재해 복구 사이트의 가상 네트워크의 CIDR과 충돌하거나 겹치지 않는지 확인합니다.

• 온-프레미스에서 기본 및 보조 Azure 재해 복구 지역으로 ExpressRoute 연결을 설정합니다.

• 온-프레미스에서 기본 및 보조 Azure 재해 복구 지역으로 VPN 연결을 설정하는 것이 좋습니다. ExpressRoute를 사용하는 대신 이 메서드를 사용합니다.

• Site Recovery를 사용하여 애플리케이션 서버를 재해 복구 사이트에 복제합니다. Site Recovery는 중앙 서비스 클러스터 VM을 재해 복구 사이트에 복제하는 데 도움이 될 수도 있습니다. 재해 복구를 호출할 때 재해 복구 사이트에서 Linux Pacemaker 클러스터를 다시 구성해야 합니다. 예를 들어 가상 IP 주소 또는 SBD를 바꾸거나 corosync.conf를 실행해야 할 수 있습니다.

• 재해 복구 지역의 데이터를 해독할 수 있도록 지역 간에 인증서, 비밀 또는 키와 같은 키 자격 증명 모음 콘텐츠를 복제합니다.

• Azure NetApp Files에서 지역 간 복제를 사용하여 기본 지역과 재해 복구 지역 간에 파일 볼륨을 동기화합니다.

• Site Recovery 대신 기본 데이터베이스 복제를 사용하여 재해 복구 사이트에 데이터를 동기화합니다.

• 기본 및 재해 복구 가상 네트워크를 피어링합니다. 예를 들어 HANA 시스템 복제의 경우 SAP HANA DB 가상 네트워크 요구 사항을 재해 복구 사이트의 SAP HANA DB 가상 네트워크와 피어해야 합니다.

• SAP 배포에 Azure NetApp Files 스토리지를 사용하는 경우 두 지역의 프리미엄 계층에서 최소한 두 개의 Azure NetApp Files 계정을 만듭니다.

• 애플리케이션 성능에 따라 비즈니스 중요도 및 근접 종속성에 따라 시스템을 그룹화하는 것이 좋습니다. 지역 가동 중단의 비즈니스 효과를 최소화하려면 각 그룹을 쌍을 이루는 지역 구문의 별도 지역에 배포합니다. 예를 들어 지역 가동 중단의 영향을 최소화하기 위해 영국 남부 및 영국 서부의 두 개의 서로 다른 사업부를 제공하는 두 개의 중요한 ERP 중앙 구성 요소 시스템을 배포할 수 있습니다.

다음 단계

Azure에서 SAP에 대한 배포 옵션