모범 사례 10.3 - 중요 SAP 데이터의 가용성을 보장할 수 있도록 접근 방식 정의 - SAP Lens

모범 사례 10.3 - 중요 SAP 데이터의 가용성을 보장할 수 있도록 접근 방식 정의

SAP 애플리케이션의 비즈니스 데이터는 주로 데이터베이스에 저장되지만 바이너리(예: 실행 파일, 라이브러리, 스크립트), 구성 및 인터페이스에 대한 파일 기반 데이터도 포함될 수 있습니다. 선택한 접근 방식은 내구성, 일관성 및 복구 옵션이 데이터 중요도 및 허용 가능한 데이터 손실(RPO) 수준에 부합하는지 검토해야 합니다.

제안 사항 10.3.1 – MTTR 요구 사항을 평가하고 그 충족 방법을 식별

[안정성] 제안 사항 10.1.5 - 허용 가능한 최소 가동 시간(%)을 정의 에서 각 애플리케이션의 MTTR 요구 사항을 정의합니다. 장애 위험과 시스템 가용성을 보호하기 위한 메커니즘을 평가한 후에는 요구 사항이 충족될 수 있는지 확인하고 각 장애 시나리오에 대한 MTTR 기대치를 문서화합니다. 비용, 복잡성 또는 일관성에 대한 절충이 필요한 경우 비즈니스 소유자와 상의하여 합의를 도출합니다.

제안 사항 10.3.2 – 백업으로부터 복구가 필요한 장애 시나리오를 결정

백업은 가용성을 보장 또는 복구하기 위한 보조 메커니즘인 경우가 많지만 대부분의 아키텍처는 어느 정도 백업에 의존합니다. 다음은 분석을 안내하는 데 사용할 수 있는 장애 시나리오의 예입니다. 시나리오 세분 수준, 분류 및 영향은 요구 사항 및 아키텍처에 따라 달라집니다.

상대적 발생 위험 백업 필요 데이터 손실 가능성 예상 복구 시간
계획/제어된 유지 관리 계획
리소스 고갈 또는 손상(높은 CPU 사용률/파일 시스템 가득 참/메모리 부족/스토리지 문제) 보통
분산형 무상태 구성 요소 장애(예: 웹 디스패처) 보통
분산형 상태 유지 구성 요소 장애(예: 애플리케이션 서버) 보통
단일 장애 지점(데이터베이스/SAP 중앙 서비스) 보통
AZ/네트워크 장애 낮음
핵심 서비스 장애(DNS/Amazon EFS/API 호출) 낮음/보통
손상/우발적 삭제/악의적 활동/잘못된 코드 배포 낮음
리전 장애 매우 낮음

제안 사항 10.3.3 – 데이터 복제가 필요한 영역을 결정

데이터 복제는 동일한 데이터의 복사본을 여러 위치에 배치하여 안정성을 개선하는 데 사용되며 RPO가 낮은 시스템의 요구 사항인 경우가 많습니다. 가용성 또는 복구를 위해 복제가 필요한지 여부를 결정할 때 서비스가 영역 단위(예: Amazon EC2 및 Amazon EBS 및 해당 서비스가 지원하는 데이터베이스) 또는 리전 단위(예: 공유 스토리지 및 Amazon S3)인지 고려합니다.

데이터베이스 복제 기술 Guidance
SAP HANA HANA System Replication SAP 설명서: HANA System Replication
SAP ASE SAP Replication Server SAP 설명서: SAP Replication Server
Oracle Oracle Data Guard SAP Note: 105047 - SAP 환경에서 Oracle 기능 지원 [SAP 포털 액세스 권한 필요]
Microsoft SQL Server SQL Server Always ON
SAP MaxDB MaxDb Standby Database SAP Note: 952783 - FAQ: SAP MaxDB 고가용성 [SAP 포털 액세스 권한 필요]
IBM Db2 HADR SAP Note: 1612105 - DB6: FAQ on Db2 High Availability Disaster Recovery(HADR) [SAP 포털 액세스 권한 필요]

AWS DataSync 는 필요한 경우 리전 간에 Amazon EFS 및 Amazon FSx 를 모두 보호하는 데 사용할 수 있습니다.

CloudEndure Disaster Recovery 는 AWS 계정 간을 포함하여 가용 영역 또는 리전 간에 인스턴스 수준에서 지속적으로 복제합니다.

Amazon S3 복제

백업 및 기타 객체 스토리지는 Amazon S3에 저장할 수 있으며 Amazon S3 복제 를 사용하여 복제할 수 있습니다.

제안 사항 10.3.4 – 구성 데이터 및 바이너리의 일관성을 보장하는 전략을 수립

장애 발생 후 예측 가능한 동작과 테스트된 설정을 보장하기 위해 구성 데이터 및 바이너리의 일관성을 유지하는 것이 중요합니다. 여기에는 운영 체제 패키지, 애플리케이션 파라미터, 클러스터 구성이 포함될 수 있습니다. 복원력을 위해 존재하는 인스턴스(예: 추가 애플리케이션 서버, 세컨더리 데이터베이스 노드)를 포함하여 애플리케이션의 모든 인스턴스에서 일관성을 보장할 수 있는 방법을 결정합니다.

Amazon EFS, Amazon FSx 및 Amazon S3는 중앙에서 관리할 수 있는 구성 또는 공유 바이너리에 대한 고내구성 위치를 제공합니다.

버전 제어 및 구성 관리를 위한 메커니즘은 [운영 우수성] 원칙의 모범 사례 2.1 - 버전 관리 및 구성 관리 사용 을 참조하세요.

제안 사항 10.3.5 – 데이터 일관성에 대한 전체적 접근 방식을 채택

중요한 SAP 데이터의 일관성을 보장하는 접근 방식은 단일 데이터 집합에 초점을 맞출 뿐만 아니라 데이터 집합과 시스템 간의 종속성도 고려해야 합니다. 예를 들어 SAP BW 시스템을 복구해야 하지만 이 시스템이 데이터를 가져오는 소스 시스템은 복구할 필요가 없는 경우 변경 포인터에 미치는 영향은 무엇이며 일관된 복구를 보장하기 위한 메커니즘은 무엇입니까?

제안 사항 10.3.6 – 데이터를 재생 또는 재전송할 수 있는 인터페이스에 대한 전략을 수립

시스템 간 데이터 교환의 경우 통합이 소결합 방식인지 여부와 데이터를 소스 또는 대상에서 재생하거나 재전송할 수 있는지 여부를 결정합니다. 중단 중에 시나리오를 일시 중단하거나 캐시할 수 있도록 대기열 기능이 있는지 검토합니다.

제안 사항 10.3.7 – 데이터 벙커 사용을 평가

우발적 삭제 또는 악의적 행위와 같은 상황으로 인해 온라인 데이터가 불안정해지거나 사용할 수 없게 되는 장애 시나리오에는 데이터 보호 또는 복구를 보장하는 데 도움이 되는 다른 접근 방식이 필요할 수 있습니다.

네트워크 격리, 액세스 제어 등의 보안 프레임워크를 통한 예방이 최선의 방어이지만 복구 및 복원력 측면에서 영향을 고려해야 합니다.

보존 기간이 단축된 쓰기 전용 백업 계정을 사용하는 것은 드물지만 잠재적 영향이 큰 시나리오에 대한 일반적인 접근 방식입니다.