SAP 마이그레이션에 대 한 엔터프라이즈 규모의 비즈니스 연속성 및 재해 복구

시나리오 및 범위

조직 또는 엔터프라이즈는 응용 프로그램 워크 로드에서 특정 요구 사항을 충족 하는 데 도움이 되는 플랫폼 수준 기능을 디자인 해야 합니다. 조직의 가장 중요 한 비즈니스 프로세스를 실행 하는 SAP 응용 프로그램에는 다음과 같은 요구 사항이 있습니다.

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

  • 실패 또는 재해 시나리오 중의 복구 시간 목표 (RTOs) 예를 들어 장애 시나리오는 SAP 시스템의 구성 요소 또는 데이터 센터 또는 Azure 지역에 영향을 주는 광범위 한 오류로 제한 됩니다.

  • SAP 시스템의 구성 요소 또는 데이터 센터 또는 Azure 지역에 영향을 주는 광범위 한 오류 시나리오에 대 한 Rpo (복구 지점 목표)

  • 운영 및 수명 주기 관리 작업에는 오류 시나리오에 맞는 기술이 필요할 수 있습니다. 이러한 관리 작업에는 게스트 운영 체제, 데이터베이스 관리 시스템 패치, SAP 시스템 복제 및 새로 고침 등이 포함 됩니다.

아키텍처는 온-프레미스에서 BCDR (비즈니스 연속성 및 재해 복구) 시나리오를 처리 하기 위한 다양 한 원칙과 작업에서 적용 되며 Azure에도 적용 됩니다. 주요 차이점은 Azure에 호스트 오류를 보정 하는 조직 보다 하드웨어 용량이 더 많은 것입니다. 가장 큰 Azure Vm도 다른 서버에서 다시 시작 하도록 하 여 서비스를 제거할 수 있습니다. 이 외에도 동일한 조건이 온-프레미스와 동일 하 게 적용 됩니다. 온-프레미스 또는 운영 체제 미 설치 하드웨어에서 자동 장애 조치 (failover) 클러스터 구성을 사용 하 여 배포한 시스템도 이러한 방식으로 Azure에 배포 되어야 합니다.

이 문서에서는 엔터프라이즈급 SAP 시나리오에 대 한 BCDR의 다음과 같은 측면에 대해 설명 합니다.

  • Azure 지역 내의 HA (고가용성)
  • 백업/복원 고려 사항
  • DR: 지역 간 및 지역 DR 결정 기준

Azure 지역 내의 HA (고가용성)

HA에 대 한 디자인 고려 사항:

HA를 사용 하면 다음과 같은 SAP 소프트웨어의 단일 실패 지점에 대 한 가용성을 제공 하는 데 중점을 둡니다.

  • 데이터베이스 관리 시스템
  • ABAP SAP ASCS/SCS와 같이 응용 프로그램의 단일 실패 지점이 있습니다 (예: SAP NetWeaver 및 S/4HANA 아키텍처 사용).
  • SAP 웹 디스패처와 같은 기타 도구

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

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

Azure VM에서 지원 되 SAP HANA(대규모 인스턴스)는 시나리오 및 지원 되는 시나리오 에 대 한 sap 워크 로드 를 살펴보고 azure에서 sap에 대해 지 원하는 기능에 대해 자세히 알아보세요.

DBMS 계층의 경우 공통 아키텍처 패턴은 기본 및 보조 Vm에서 사용 하는 것과 다른 저장소 스택을 사용 하 여 동시에 데이터베이스를 복제 하는 것입니다. Azure는 DBMS 데이터를 위해 기본 및 보조 VM이 저장소를 공유 하는 아키텍처를 지원 하지 않으며 트랜잭션/다시 실행 로그도 지원 하지 않습니다. 보안 주체는 NFS (네트워크 파일 시스템) 공유를 기반으로 하는 경우에도 두 개의 독립 된 저장소 스택이 있어야 하며,이는 온-프레미스에서 가능한 것과 비교할 때의 주요 제한 사항입니다.

서비스에서 NFS 또는 서버 메시지 블록 공유를 지원 하기 때문에 Azure는 다른 옵션을 제공 합니다. Windows에서 ASCS/SCS 구성 요소 및 특정 HA 시나리오에 대해 Azure 공유 디스크 를 사용할 수 있습니다. Azure는 sap 응용 프로그램 계층 구성 요소와 DBMS 계층을 하나의 장애 조치 (failover) 클러스터로 결합 하는 HA 아키텍처를 지원 하지 않으므로 SAP 응용 프로그램 계층 구성 요소 및 DBMS 계층에 대해 개별적으로 장애 조치 클러스터를 설정 해야 합니다

SAP 응용 프로그램 계층 구성 요소 및 DBMS 계층의 대부분 장애 조치 (failover) 클러스터에는 장애 조치 (failover) 클러스터에 대 한 가상 IP 주소가 필요 한 가지 일반적인 예외는 해당 기능에 가상 IP 주소가 필요 하지 않은 Oracle Data Guard를 사용 하는 것입니다. 다른 모든 경우에는 가상 IP 주소를 처리 해야 Azure Load Balancer . 디자인 원칙으로 클러스터 구성 마다 Load Balancer 하나를 사용 합니다. 표준 버전의 부하 분산 장치를 권장 합니다. 자세한 내용은 SAP HA 시나리오에서 Azure 표준 Load Balancer를 사용 하는 가상 컴퓨터에 대 한 공용 끝점 연결을 참조 하세요.

자세한 정보 및 가능성은 SAP NetWeaver에 대 한 HA 아키텍처 및 시나리오 를 살펴보세요.

Azure 가용성 집합 및 가용성 영역

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

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

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

다른 가용성 영역에 HA 아키텍처를 배포 하는 경우의 이점 중 하나는 Vm에 대 한 SLA가 높을 수 있다는 것입니다. 자세한 내용은 AZURE VM sla를 검토 하세요. Azure 지역에 따라 Vm 간의 네트워크 트래픽에 다른 네트워크 대기 시간 조건을 발견할 수 있습니다. 여러 가용성 영역에서 SAP 워크 로드 배포에 대 한 자세한 내용은 Azure 가용성 영역를 사용 하 여 sap 워크 로드 구성 을 참조 하세요.

HA에 대 한 디자인 권장 사항:

  • Azure는 응용 프로그램이 인프라 Sla를 충족 하는 데 도움이 되는 몇 가지 옵션을 제공 합니다. 세 가지 SAP 구성 요소 (중앙 서비스, 응용 프로그램 서버 및 데이터베이스) 모두에 대해 동일한 옵션을 선택 해야 합니다.

    • 단일 VM SLA는 99.9%를 제공 합니다.
    • 가용성 집합 배포는 99.95%를 제공 합니다.
    • 가용성 영역 제품은 99.99%입니다.
  • 가용성 집합 배포에서 SAP 시스템의 각 구성 요소는 자체 가용성 집합에 있어야 합니다. SAP central services, 데이터베이스 및 응용 프로그램 Vm은 가용성 집합에서 그룹화 해야 합니다.

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

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

  • Azure는 현재 동일한 Linux Pacemaker 클러스터에서 ASCS와 db HA를 조합 하 여 지원 하지 않습니다. 개별 클러스터로 구분 합니다. 그러나 최대 5 개의 중앙 서비스 클러스터 를 하나의 vm으로 결합할 수 있습니다.

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

  • 모든 프로덕션 시스템은 프리미엄 관리 Ssd에서 실행 되 고 Azure NetApp Files 또는 ultra disks를 사용 해야 합니다. 최소한의 OS 디스크는 더 나은 성능과 최상의 SLA를 얻기 위해 프리미엄 계층 이어야 합니다.

  • HA 쌍의 두 Vm은 가용성 집합에 배포 해야 합니다. 그렇지 않으면 가용성 영역 크기와 저장소 구성이 동일 해야 합니다.

  • 네이티브 데이터베이스 복제 기술은 HA 쌍의 데이터베이스를 동기화 하는 데 사용 해야 합니다.

  • 여러 운영 체제에서 SAP central service 클러스터를 실행 하려면 다음 서비스 중 하나를 선택 해야 합니다.

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

백업/복원

백업/복원에 대 한 디자인 고려 사항:

백업 및 복원은 일반적으로 프로덕션 SAP 워크 로드에 대 한 적절 한 HA 기능으로 간주 되지 않지만이 기술은 다양 한 기타 영역을 다룹니다. SAP 응용 프로그램을 사용 하는 대부분의 회사는 백업이 여러 년 동안 저장 되어야 하는 규정 준수 규정을 준수 해야 합니다. 백업 및 복원할 수 있는 다른 조건 및 시나리오도 반드시 필요 합니다. SAP 응용 프로그램을 배포 하기 위한 백업 및 복원 모범 사례를 이미 설정 하 고 따르는 것으로 가정 합니다. 즉 다음을 수행할 수 있습니다.

  • 언제 든 지 RTO를 충족 하는 시간 프레임 내에 프로덕션 데이터베이스에 대 한 특정 시점 복구를 수행 합니다. 일반적으로 지정 시간 복구에는 DBMS 계층에서 또는 SAP를 통해 데이터를 삭제 하는 운영자 오류가 포함 됩니다.

  • 규정 준수 규정을 충족 하는 장기 백업을 유지 하는 저장소를 유지 관리 합니다.

  • 데이터베이스 백업을 사용 하 여 SAP 시스템을 복제 하 고 다른 서버/v m에 대해 복원 합니다.

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

  • SAP 응용 프로그램 서버/v m, 디스크 또는 VM 스냅숏을 백업 합니다.

온-프레미스에서이 작업을 수행할 수 있는 경우 Azure에서 이러한 기능을 SAP 시스템으로 가져와야 합니다.

현재 솔루션에 만족 하는 경우 백업 공급 업체에서 Azure 배포를 지원 하는지 또는 Azure에서 SaaS (software as a service) 솔루션을 설정 했는지 확인 합니다.

Azure는 VM 스냅숏을 사용 하 고 스트리밍 SQL ServerSAP HANA 백업을 관리 하는 Azure Backup백업 SaaS 서비스를 제공 합니다. Azure NetApp Files 를 사용 하 여 SAP HANA 데이터베이스를 저장 하는 경우 HANA 일관 된 저장소 스냅숏을 기반으로 백업을 수행할 수 있습니다.

백업/복원에 대 한 디자인 권장 사항:

  • Azure Backup를 사용 하 여 SAP 응용 프로그램 서버 및 중앙 서비스 Vm을 백업할 수 있습니다.

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

  • 백업 및 복구 시간을 테스트 하 여 RTO를 충족 하는지 확인 합니다.

  • Azure에서 온-프레미스 백업 인프라 (특히 데이터베이스 규모가 큼)로 백업을 가져오는 것은 권장 되지 않습니다. 이 옵션은 Express 경로 회로에서 사용 하는 대역폭의 양에 영향을 줍니다.

DR

DR에 대 한 디자인 고려 사항:

Azure 지역 맵은 60 개 이상의 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 기능을 사용 하 여 사용자 고유의 복제를 수행 합니다. rsync / robocopy SAP 응용 프로그램 계층에 대 한 Azure Site Recovery, 및 기타 타사 소프트웨어의 조합을 사용 합니다.

Azure 지역을 정의한 후에는 프로덕션 시스템을 주 지역에 배포할지, SAP 시스템을 DR 지역으로 비프로덕션, dr 지역이 DR 지역 에서만 사용 되도록 모든 SAP 시스템을 주 지역으로 그룹화 하는 아키텍처를 사용 하 고 있는지를 고려해 야 합니다. 현재 SAP 고객 배포 패턴은 운영 중인 SAP 시스템에 대해 두 지역을 모두 사용 하는 대부분의 고객을 보여 줍니다. 일반적으로 비즈니스 회귀 테스트 시스템으로 프로덕션 시스템의 전체 복사본을 실행 하는 고객은 일반적으로 SAP 제품 라인의 비즈니스 회귀 테스트 시스템을 DR 대상으로 사용할 계획입니다.

두 개 이상의 Azure 지역 중 하나를 확인 하는 또 다른 중요 한 디자인 요인은 Azure에 연결 하는 여러 Azure Express 경로 회로가 있는 경우입니다. 하나 이상의 Express 경로 회로를 기본 Azure 지역에 연결 해야 하며, 다른 하나는 DR 지역에 연결 해야 합니다. 이러한 유형의 아키텍처는 다른 지역에 있는 Azure 네트워크에 연결 하 여 재해가 있는 경우 다른 Azure 지역에 연결 해야 합니다.

일부 고객은 ha/DR 아키텍처를 사용 하며,이 아키텍처는 동일한 Azure 지역에서 DR을 사용 하 여 HA를 그룹화 하 고 일반적으로 권장 되지 않습니다. 이 아키텍처는 Azure 가용성 영역 지원 합니다. 한 Azure 지역 내의 가용성 영역 간 거리는 서로 다른 두 Azure 지역 간의 거리 만큼 크지 않으므로 자연 재해는 발생 하는 지역에서이 아키텍처를 위협할 수 있습니다. 고객은 다음을 수행 하 여이 아키텍처를 선택 합니다.

  • 프로덕션 배포와 DR 대상 간의 더 작은 거리를 지 원하는 구성에서 충분 한 규정 준수
  • 데이터 주권 측면
  • 지정 학적 요소

DR 지역을 선택할 때 고려해 야 할 또 다른 요소는 DR 사이트로 장애 조치 (failover) 하는 RPO 및 RTO입니다. 프로덕션 및 DR 지역 간의 거리를 늘리면 네트워크 대기 시간이 길어집니다. 서로 다른 Azure 지역 간에 비동기적으로 복제 하는 경우에는 더 작거나 더 큰 네트워크 대기 시간이 복제할 수 있는 처리량 및 RPO 대상에 영향을 줄 수 있습니다. HA/DR 아키텍처를 사용 하 여 RPO를 최소화 하는 것이 일반적 이지만 대규모 자연 재해에서 잠재적 위험이 높아질 수 있습니다.

DR에 대 한 디자인 권장 사항:

  • 기본 VNet (가상 네트워크)에 대 한 CIDR이 DR 사이트 VNet의 CIDR과 충돌 하거나 중복 되어서는 안 됩니다.

  • 온-프레미스에서 기본 및 보조 Azure DR 지역으로 Express 경로 연결을 설정 합니다.

  • Express 경로를 사용 하는 대신 온-premies에서 기본 및 보조 Azure DR 지역으로 VPN 연결을 설정 합니다.

  • Site Recovery를 사용 하 여 응용 프로그램 서버를 DR 사이트에 복제 합니다. Site Recovery은 DR 사이트에 중앙 서비스 클러스터 Vm을 복제 하는 데도 도움이 될 수 있습니다. DR을 호출 하는 경우 DR 사이트에서 Linux Pacemaker 클러스터를 다시 구성 해야 합니다 (예: VIP 또는 SBD, 실행 corosync.conf 등 대체).

  • Azure NetApp Files에서 지역 간 복제를 사용 하 여 기본 및 DR 지역 간에 파일 볼륨을 동기화 합니다. 지역 간 복제는 현재 공개 미리 보기로제공 됩니다.

  • 네이티브 데이터베이스 복제를 사용 하 여 DR 사이트와 데이터를 동기화 해야 합니다. Site Recovery를 사용할 수 없습니다.

  • 기본 및 DR Vnet을 피어 링 합니다. 예를 들어 HANA 시스템 복제의 경우 SAP HANA DB VNet을 DR 사이트의 SAP HANA DB VNet에 피어 링 해야 합니다.

  • SAP 배포를 위해 Azure NetApp Files 저장소를 사용 하는 경우 최소한 프리미엄 계층에서 두 개의 Azure NetApp Files 계정을 만들어야 합니다.