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

이 문서는 BCDR용 Azure 랜딩 존 디자인 영역에 정의된 몇 가지 고려 사항 및 권장 사항을 기반으로 합니다. 이 문서는 SAP 플랫폼을 지원하는 모든 랜딩 존의 고유한 제약 조건을 이해하는 데 도움이 될 수 있습니다. SAP는 중요 업무용 플랫폼이므로 이 문서의 Azure 랜딩 존 디자인 영역 섹션에 제시된 다른 지침을 참조하여 디자인에 통합해야 합니다.

시나리오 및 범위

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

• 서비스 및 비즈니스 프로세스 가용성.
• 오류 또는 재해 시나리오에 대한 RTO(복구 시간 목표)입니다.
• 실패 시나리오에 대한 RPO(복구 지점 목표)입니다.
• 운영 및 수명 주기 관리 작업 및 실패 시나리오 중에 채우는 기술입니다. 이러한 관리 작업에는 게스트 운영 체제 및 데이터베이스 관리 시스템 패치, 복제, SAP 시스템 새로 고침이 포함됩니다.

팁

SAP 환경의 각 아키텍처 유형에 대한 HADR(고가용성 및 재해 복구) 솔루션을 조기에 동의합니다. 모든 SAP 구성 요소가 적절한 솔루션으로 덮여 있는지 확인합니다.

하나 이상의 환경에서 Azure의 HADR을 조기에 구성하고 계속 실행합니다. 이렇게 하면 팀이 기존 기술과 다를 수 있는 관련 기술에 대한 경험을 얻을 수 있는 기회를 얻을 수 있습니다. HADR을 조기에 구성하면 SOP(표준 운영 절차)를 개발하고 발전시키는 데도 도움이 될 수 있습니다.

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

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

• Azure 지역 내의 고가용성.
• 백업 및 복원 고려 사항
• 지역 간 및 지역 재해 복구를 결정하는 기준입니다.

Azure 지역 내의 고가용성

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

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

고가용성을 사용하면 다음과 같은 SAP 소프트웨어의 단일 실패 지점에 대한 가용성을 제공하는 것이 중요합니다.

• 데이터베이스 관리 시스템.
• SAP ABAP 및 ASCS + SCS와 같은 애플리케이션의 단일 실패 지점. 예를 들면 SAP NetWeaver 및 SAP S/4HANA 아키텍처가 있습니다.
• SAP Web Dispatcher와 같은 기타 도구.

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

SAP 및 SAP 데이터베이스는 자동 장애 조치(failover) 클러스터를 지원합니다. Windows의 경우, Windows Server 장애 조치(failover) 클러스터링이 장애 조치(failover)를 지원합니다. Linux의 경우, Linux Pacemaker 또는 SIOS Protection Suite 및 Veritas InfoScale과 같은 타사 도구가 장애 조치(failover)를 지원합니다. Azure를 사용하면 고유한 데이터 센터에 하위 집합 고가용성 구성만 배포할 수 있습니다.

Azure에서 SAP를 지원하는 방식에 대해 자세히 알아보려면 Azure VM의 SAP 워크로드에 지원되는 시나리오 및 SAP HANA 대규모 인스턴스에 지원되는 시나리오를 참조하세요.

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

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

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

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

다음은 다양한 고가용성 배포 옵션에 대한 플랫폼 수준 SLA입니다. 관리되는 서비스를 제공하는 파트너는 애플리케이션 수준 SLA를 제공합니다.

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

자세한 내용은 다음 단원을 참조하세요.

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

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

• VM은 서로 다른 가용성 영역에 분산되지 않습니다.
• 호스트는 집합에 배포된 첫 번째 VM에 의해 정의되므로 단일 가용성 집합을 통해 배포할 수 있는 VM 유형이 제한됩니다. 한 가지 예제 결과는 M 시리즈와 E 시리즈 VM을 하나의 가용성 집합으로 결합할 수 없다는 것입니다.

다양한 가용성 영역에 고가용성 아키텍처를 배포할 때의 이점은 VM에 대한 SLA(서비스 수준 약정)가 더 높아질 수 있다는 것입니다. 자세한 내용은 Azure VM SLA를 참조하세요. Azure 지역에 따라 VM 간의 네트워크 트래픽에서 서로 다른 네트워크 대기 시간 조건을 검색할 수 있습니다. 자세한 내용은 Azure 가용성 영역을 사용하여 SAP 워크로드 구성을 참조하세요.

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

애플리케이션 서버 계층에 대해 액티브/패시브 영역 배포를 사용하는 경우(애플리케이션 서버는 동일한 가용성 영역의 데이터베이스에 연결해야 함), 데이터베이스 장애 조치(failover)가 있는 경우 빠르고 자동화된 복구를 사용하도록 자동화 및 SOP를 빌드합니다.

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

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

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

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

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

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

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

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

• 근접 배치 그룹을 사용하는 경우 SAP SID당 하나를 사용합니다. 그룹은 가용성 영역 또는 Azure 지역에 걸쳐 있지 않습니다.

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

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

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

• 프리미엄 관리 SSD에서 모든 프로덕션 시스템을 실행하고 Azure NetApp Files 또는 Ultra Disk Storage를 사용합니다. 적어도 OS 디스크는 더 나은 성능과 최상의 SLA를 달성하기 위해 프리미엄 계층이어야 합니다.

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

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

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

  • SUSE Linux Enterprise Server Pacemaker 클러스터. Azure 펜스 에이전트와 최대 3개의 STONITH 블록 디바이스(SBD)가 지원됩니다.
  • Red Hat Enterprise Linux Pacemaker 클러스터. SBD는 현재 지원되지 않습니다. Azure 펜스 에이전트만 지원됩니다.
  • Windows 클러스터.
  • SAP 인증 타사 클러스터 소프트웨어

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

SAP 워크로드용 스토리지

• 올바른 스토리지 옵션을 선택하는 것은 SAP 워크로드의 복원력을 위한 디자인의 일부입니다. Azure Storage의 SAP 워크로드는 대기 시간을 최소로 유지하고 처리량을 최대화하도록 디자인되어 있습니다. 구현과 다음 지침이 Azure의 SAP 구현에 대한 아키텍처 결정을 내리는 데 어떻게 도움이 되는지 고려합니다. 다양한 유형의 스토리지 및 SAP 워크로드 및 구성 요소와의 호환성에 대한 자세한 내용은 SAP 워크로드용 Azure Storage 유형을 참조하세요.

• SAP에서 인증된 스토리지 유형에서만 Azure에서 SAP HANA를 실행해야 합니다. 특정 볼륨은 해당하는 경우 특정 디스크 구성에서 실행해야 합니다. 이러한 구성에는 Write Accelerator 사용 및 Premium Storage 사용이 포함됩니다. 또한 스토리지에서 실행되는 파일 시스템이 컴퓨터에서 실행되는 DBMS와 호환되는지 확인해야 합니다. 자세한 내용은 SAP HANA에 대한 스토리지 구성을 참조하세요.

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

  스토리지 유형	고가용성 구성 지원
  Azure 공유 디스크(LRS 또는 ZRS)	Windows Server 장애 조치(failover) 클러스터. 구성 세부 정보는 Windows Server 장애 조치(failover) 클러스터링 SAP HA 디자인을 참조하세요.
  Azure Files NFS(LRS 또는 ZRS)	Linux 환경의 Pacemaker 기반 클러스터. 다른 지역에서 NFS의 가용성을 검사 합니다.
  Azure NetApp Files의 NFS	Linux 환경의 Pacemaker 기반 클러스터. 자세한 내용은 SAP 가상 머신에 대한 Azure NetApp Files를 참조하세요.
  Azure Files SMB(LRS 또는 ZRS)	Windows Server 장애 조치(failover) 클러스터. 구성 세부 정보는 SAP 애플리케이션용 Azure Files 프리미엄 SMB를 사용하는 Windows의 Azure VM에서 SAP NetWeaver에 대한 고가용성을 참조하세요.
  Azure NetApp Files의 SMB	Windows Server 장애 조치(failover) 클러스터. 구성 세부 정보는 SAP 애플리케이션용 SMB(Azure NetApp Files)가 있는 Windows의 Azure VM에서 SAP NetWeaver에 대한 고가용성을 참조하세요.

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

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

백업 및 복원

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

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

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

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

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

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

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

온-프레미스에서 백업 및 복원하는 경우 이러한 기능을 Azure의 SAP 시스템에 가져와야 합니다.

현재 솔루션에 만족하는 경우 백업 공급업체가 Azure 배포를 지원하는지 또는 Azure용 SaaS(Software as a Service) 솔루션이 있는지 확인합니다.

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

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

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

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

• IaaS 백업 솔루션을 사용하는 경우 백업 인프라의 크기를 조정하여 예상 시간 프레임 내에서, 그리고 네트워킹, 보안 등의 측면에서 프로덕션 설정 또는 유사한 설정을 사용하여 모든 프로덕션 크기의 시스템을 동시에 백업하거나 실제 시나리오에서처럼 백업할 수 있도록 합니다.

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

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

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

재해 복구

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

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

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

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

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

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

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

또 다른 중요한 고려 사항은 재해 지역에서 필요한 운영 용량을 보호하는 것입니다. 재해가 발생하는 경우 주 지역에서 정상 작업을 복구하는 동안에만 최소한의 IT 용량과 중요한 인적 자원으로 최소한의 시간 동안 SAP 애플리케이션을 실행해야 할 수 있습니다. 이렇게 하려면 DR 지역에서 사용할 수 있는 최소한의 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 연결을 설정합니다.
• ExpressRoute를 사용하는 대신 온-프레미스에서 기본 및 보조 Azure 재해 복구 지역으로 VPN 연결을 설정하는 것이 좋습니다.
• Site Recovery를 사용하여 애플리케이션 서버를 재해 복구 사이트에 복제합니다. Site Recovery 중앙 서비스 클러스터 VM을 재해 복구 사이트에 복제하는 데도 도움이 될 수 있습니다. 재해 복구를 호출할 때 재해 복구 사이트에서 Linux Pacemaker 클러스터를 다시 구성해야 합니다. 예를 들어 VIP 또는 SBD를 바꾸고 corosync.conf를 실행하는 등의 작업을 수행해야 합니다.
• DR 지역의 데이터를 해독할 수 있도록 지역 간에 인증서, 비밀 또는 키와 같은 키 자격 증명 모음 콘텐츠를 복제합니다.
• Azure NetApp Files 지역 간 복제(현재 공개 미리 보기)를 사용하여 주 지역과 재해 복구 지역 간에 파일 볼륨을 동기화합니다.
• Site Recovery 대신 기본 데이터베이스 복제를 사용하여 재해 복구 사이트에 데이터를 동기화합니다.
• 기본 및 재해 복구 가상 네트워크를 피어링합니다. 예를 들어 HANA 시스템 복제의 경우 SAP HANA DB 가상 네트워크를 가상 네트워크 사이트의 SAP HANA DB 가상 네트워크에 피어링해야 합니다.
• SAP 배포에 Azure NetApp Files 스토리지를 사용하는 경우 두 지역의 프리미엄 계층에서 최소한 두 개의 Azure NetApp Files 계정을 만듭니다.
• 애플리케이션 성능에 따라 비즈니스 중요도 및 근접 종속성에 따라 시스템을 그룹화하는 것이 좋습니다. 각 그룹을 쌍을 이루는 지역 구문의 별도 지역에 배포하여 지역 가동 중단의 비즈니스 영향을 최소화합니다. 예를 들어 두 개의 서로 다른 사업부를 제공하는 두 개의 중요한 ECC 시스템을 영국 남부와 영국 서부에 배포하여 지역 가동 중단의 영향을 최소화할 수 있습니다.

다음 단계

Azure의 SAP 배포 옵션