

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# AWS 기반 IBM Db2에서 SAP를 위한 재해 복구 설정
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws"></a>

*Ambarish Satarkar, Debasis Sahoo, Amazon Web Services*

## 요약
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-summary"></a>

이 패턴은 데이터베이스 플랫폼으로 IBM Db2를 사용하여 Amazon Web Services(AWS) 클라우드에서 실행되는 SAP 워크로드용 재해 복구(DR) 시스템을 설정하는 단계를 설명합니다. 목표는 정전 발생 시 비즈니스 연속성을 제공하는 저비용 솔루션을 제공하는 것입니다.

이 패턴은 [파일럿 라이트 접근 방식](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)을 사용합니다. AWS에서 파일럿 라이트 DR을 구현하여 다운타임을 줄이고 비즈니스 연속성을 유지할 수 있습니다. 파일럿 라이트 접근 방식은 프로덕션 환경과 동기화된 SAP 시스템 및 스탠바이 Db2 데이터베이스를 포함하여 AWS에서 최소 DR 환경을 설정하는 데 중점을 둡니다.

이 솔루션은 확장이 가능합니다. 필요에 따라 전체 규모 재해 복구 환경으로 확장할 수 있습니다.

## 사전 조건 및 제한 사항
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-prereqs"></a>

**사전 조건 **
+ Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행되는 SAP 인스턴스
+ IBM Db2 데이터베이스
+ SAP 제품 가용성 매트릭스(PAM)에서 지원하는 운영 체제
+ 운영 및 스탠바이 데이터베이스 호스트의 서로 다른 물리적 데이터베이스 호스트 이름
+ [교차 리전 복제(CRR)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)를 지원하는 각 AWS 리전의 Amazon Simple Storage Service(S3) 버킷

**제품 버전**
+ IBM Db2 데이터베이스 버전 11.5.7 이상

## 아키텍처
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-architecture"></a>

**대상 기술 스택**
+ Amazon EC2
+ Amazon Simple Storage Service(Amazon S3)
+ Amazon Virtual Private Cloud(VPC 피어링)
+ Amazon Route 53
+ IBM Db2 고가용성 재해 복구(HADR)

**대상 아키텍처**

이 아키텍처는 Db2를 데이터베이스 플랫폼으로 사용하여 SAP 워크로드용 DR 솔루션을 구현합니다. 프로덕션 데이터베이스는 AWS 리전 1에 배포되고 스탠바이 데이터베이스는 두 번째 리전에 배포됩니다. 스탠바이 데이터베이스를 DR 시스템이라고 합니다. Db2 데이터베이스는 다중 스탠바이 데이터베이스(최대 3개)를 지원합니다. Db2 HADR을 사용하여 DR 데이터베이스를 설정하고 프로덕션 및 스탠바이 데이터베이스 간의 로그 전달을 자동화합니다.

리전 1을 사용할 수 없게 될 정도의 재해가 발생하는 경우 DR 리전의 스탠바이 데이터베이스가 프로덕션 데이터베이스 역할을 대신합니다. Recovery Time Objective(RTO) 요구 사항을 충족하기 위해 SAP 애플리케이션 서버를 미리 구축하거나 [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 또는 Amazon Machine Image(AMI)를 사용하여 구축할 수 있습니다. 이 패턴은 AMI를 사용합니다.

Db2 HADR은 프로덕션-스탠바이 설정을 구현합니다. 이 경우 프로덕션이 기본 서버 역할을 하고 모든 사용자가 이 서버에 연결됩니다. 모든 트랜잭션은 TCP/IP를 사용하여 스탠바이 서버로 전송되는 로그 파일에 기록됩니다. 스탠바이 서버는 전송된 로그 레코드를 롤포워드하여 로컬 데이터베이스를 업데이트하므로 프로덕션 서버와 동기화된 상태를 유지하는 데 도움이 됩니다.

VPC 피어링은 프로덕션 지역과 DR 지역의 인스턴스가 서로 통신할 수 있도록 하는 데 사용됩니다. Amazon Route 53은 최종 사용자를 인터넷 애플리케이션으로 라우팅합니다.

![\[리전 간 복제 기능을 갖춘 AWS상의 Db2\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/images/pattern-img/06edfa4c-0827-4d05-95cf-2d2651e74323/images/e77c1e4e-36f3-4af4-89d0-8eec72348f0a.png)


1. 리전 1에 애플리케이션 서버의 [AMI를 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)하고 리전 2에 [AMI를 복사](https://repost.aws/knowledge-center/copy-ami-region)합니다. 재해 발생 시 AMI를 사용하여 리전 2에서 서버를 시작합니다.

1. 프로덕션 데이터베이스(리전 1)와 스탠바이 데이터베이스(리전 2) 간에 Db2 HADR 복제를 설정합니다.

1. 재해 발생 시 프로덕션 인스턴스와 일치하도록 EC2 인스턴스 유형을 변경합니다.

1. 리전 1에서는 `LOGARCHMETH1`이 `db2remote: S3 path`로 설정됩니다.

1. 리전 2에서는 `LOGARCHMETH1`이 `db2remote: S3 path`로 설정됩니다.

1. 교차 리전 복제는 S3 버킷 간에 수행됩니다.

## 도구
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-tools"></a>

**서비스**
+ [Amazon Elastic Compute Cloud(Amazon EC2)](https://docs.aws.amazon.com/ec2/)는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 필요한 만큼 가상 서버를 시작하고 빠르게 스케일 업하거나 스케일 다운할 수 있습니다.
+ [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)는 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.
+ [Amazon Simple Storage Service(S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.
+ [Amazon Virtual Private Cloud(VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)를 사용하면 사용자가 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 사용자의 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하며 AWS의 확장 가능한 인프라를 사용한다는 이점이 있습니다. 이 패턴은 [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)을 사용합니다.

## 모범 사례
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-best-practices"></a>
+ 네트워크는 HADR 복제 모드를 결정하는 데 중요한 역할을 합니다. AWS 리전 전반의 DR의 경우 Db2 HADR ASYNC 또는 SUPERASYNC 모드를 사용하는 것이 좋습니다. 
+ Db2 HADR의 복제 모드에 대한 자세한 내용은 [IBM 설명서](https://ibm.github.io/db2-hadr-wiki/hadrSyncMode.html#Description_of_the_Modes)를 참조십시오.
+ AWS Management Console 또는 AWS Command Line Interface(AWS CLI)를 사용하여 기존 SAP 시스템의 [새로운 AMI를 생성](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami)할 수 있습니다. 그런 다음 AMI를 사용하여 기존 SAP 시스템을 복구하거나 클론을 생성할 수 있습니다.
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)은 EC2 인스턴스 및 기타 AWS 리소스의 일반적인 유지 관리 및 배포 작업에 도움을 줄 수 있습니다.
+ AWS는 AWS의 인프라 및 애플리케이션을 모니터링하고 관리할 수 있는 여러 기본 서비스를 제공합니다. Amazon CloudWatch 및 AWS CloudTrail과 같은 서비스를 사용하여 각각 기본 인프라 및 API 작업을 모니터링할 수 있습니다. 자세한 내용은 [SAP on AWS-Pacemaker가 포함된 IBM Db2 HADR](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)을 참조하십시오.

## 에픽
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-epics"></a>

### 환경 준비
<a name="prepare-the-environment"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 시스템과 로그를 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 관리자, SAP Basis 관리자 | 

### 서버 및 복제 설정
<a name="set-up-the-servers-and-replication"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| SAP 및 데이터베이스 서버를 생성합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html)롤포워드 보류 상태는 전체 백업이 복원된 후에 기본적으로 설정됩니다. 롤포워드 보류 상태는 데이터베이스를 복원하는 중이며 일부 변경 사항을 적용해야 할 수 있음을 나타냅니다. 자세한 내용은 [IBM 설명서](https://www.ibm.com/docs/en/db2/11.5?topic=commands-rollforward-database)를 참조하십시오. | SAP Basis 관리자 | 
| 구성을 확인합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 관리자, SAP Basis 관리자 | 
| 프로덕션 DB에서 DR DB로의 복제를 설정합니다(ASYNC 모드 사용). | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP Basis 관리자 | 

### DR 장애 조치 작업 테스트
<a name="test-dr-failover-tasks"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| DR 테스트를 위한 프로덕션 비즈니스 다운타임을 계획합니다. | DR 장애 조치 시나리오를 테스트하려면 프로덕션 환경에서 필요한 비즈니스 다운타임을 계획해야 합니다. | SAP Basis 관리자 | 
| 테스트 사용자를 생성합니다. | DR 호스트에서 검증할 수 있는 테스트 사용자(또는 모든 테스트 변경 사항)를 생성하여 DR 장애 조치 후 로그 복제를 확인합니다. | SAP Basis 관리자 | 
| 콘솔에서 프로덕션 EC2 인스턴스를 중지합니다. | 이 단계에서는 재해 시나리오를 모방하기 위해 비정상 종료가 시작됩니다. | AWS 시스템 관리자 | 
| 요구 사항에 맞게 DR EC2 인스턴스를 스케일 업합니다. | EC2 콘솔에서 DR 리전의 인스턴스 유형을 변경합니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP Basis 관리자 | 
| 인계를 시작합니다. | DR 시스템(`host2`)에서 인계 프로세스를 시작하고 DR 데이터베이스를 기본 데이터베이스로 불러옵니다.<pre>db2 takeover hadr on database <SID> by force</pre>선택적으로 다음 파라미터를 설정하여 인스턴스 유형에 따라 데이터베이스 메모리 할당을 자동으로 조정할 수 있습니다. Db2 데이터베이스에 할당할 메모리 전용 부분에 따라 `INSTANCE_MEMORY` 값을 결정할 수 있습니다.<pre>db2 update db cfg for <SID> using INSTANCE_MEMORY <FIXED VALUE> IMMEDIATE;<br />db2 get db cfg for <SID> | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; <br />db2 update db cfg for <SID> using self_tuning_mem ON IMMEDIATE;</pre>다음 명령을 사용하여 문제를 확인합니다.<pre>db2 get db cfg for <SID> | grep -i MEMORY<br />db2 get db cfg for <SID> | grep -i self_tuning_mem</pre> | SAP Basis 관리자 | 
| DR 리전에서 SAP용 애플리케이션 서버를 시작합니다. | 프로덕션 시스템에서 만든 AMI를 사용하여 DR 리전에서 [새로운 추가 애플리케이션 서버를 시작합니다](https://aws.amazon.com/premiumsupport/knowledge-center/launch-instance-custom-ami/). | SAP Basis 관리자 | 
| SAP 애플리케이션을 시작하기 전에 검증을 수행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 관리자, SAP Basis 관리자 | 
| DR 시스템에서 SAP 애플리케이션을 시작합니다. | `<sid>adm` 사용자를 사용하여 DR 시스템에서 SAP 애플리케이션을 시작합니다. `XX`가 SAP ABAP SAP Central Services(ASCS) 서버의 인스턴스 번호를 나타내는 다음의 코드를 사용하십시오. `YY`는 SAP 애플리케이션 서버의 인스턴스 번호를 나타냅니다.<pre>sapconrol -nr XX -function StartService <SID><br />sapconrol -nr XX -function StartSystem<br />sapconrol -nr YY -function StartService <SID><br />sapconrol -nr YY -function StartSystem</pre> | SAP Basis 관리자 | 
| SAP 검증을 수행합니다. | 이는 증거를 제공하거나 DR 리전으로의 데이터 복제 성공 여부를 확인하기 위한 DR 테스트로 수행됩니다. | 테스트 엔지니어 | 

### DR 페일백 작업 수행
<a name="perform-dr-failback-tasks"></a>


| 작업 | 설명 | 필요한 기술 | 
| --- | --- | --- | 
| 운영 SAP 및 데이터베이스 서버를 시작합니다. | 콘솔에서 프로덕션 시스템의 SAP와 데이터베이스를 호스팅하는 EC2 인스턴스를 시작합니다. | SAP Basis 관리자 | 
| 프로덕션 데이터베이스를 시작하고 HADR을 설정합니다. | 프로덕션 시스템(`host1`)에 로그인하고 다음 명령을 사용하여 DB가 복구 모드에 있는지 확인합니다.<pre>db2start<br />db2 start HADR on db P3V as standby<br />db2 connect to <SID></pre>HADR 상태가 `connected`인지 확인합니다. 복제 상태는 `peer`여야 합니다.<pre>db2pd -d <SID> -hadr</pre>데이터베이스가 일관되지 않고 `connected` 및 `peer` 상태가 아닌 경우 (`host1`의) 데이터베이스를 (`host2` DR 리전의) 현재 활성 데이터베이스와 동기화하려면 백업 및 복원이 필요할 수 있습니다. 이 경우 `host2` DR 리전의 데이터베이스에서 `host1` 프로덕션 리전의 데이터베이스로 DB 백업을 복원합니다. | SAP Basis 관리자 | 
| 데이터베이스를 프로덕션 리전으로 페일백합니다. | 일반적인 업무 시나리오에서 이 단계는 예정된 가동 중지 시간에 수행됩니다. DR 시스템에서 실행 중인 애플리케이션이 중지되고 데이터베이스가 프로덕션 리전(리전 1)으로 페일백되어 프로덕션 리전에서 작업이 재개됩니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP Basis 관리자 | 
| SAP 애플리케이션을 시작하기 전에 검증을 수행합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | AWS 관리자, SAP Basis 관리자 | 
| SAP 애플리케이션을 시작합니다. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | SAP Basis 관리자 | 

## 문제 해결
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-troubleshooting"></a>


| 문제 | Solution | 
| --- | --- | 
| HADR 관련 문제를 해결하기 위한 주요 로그 파일 및 명령 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/patterns/set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws.html) | 
| Db2 UDB의 HADR 문제 해결을 위한 SAP 노트 | SAP [Note 1154013-DB6: HADR 환경에서의 DB 문제](https://service.sap.com/sap/support/notes/1154013)를 참조하십시오. (이 노트에 액세스하려면 SAP 포털 보안 인증 정보가 필요합니다.) | 

## 관련 리소스
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-resources"></a>
+ [AWS의 Db2 데이터베이스에 대한 재해 복구 접근 방식](https://aws.amazon.com/blogs/architecture/disaster-recovery-approaches-for-db2-databases-on-aws/)(블로그 게시물)
+ [SAP on AWS-Pacemaker를 포함한 IBM Db2 HADR](https://docs.aws.amazon.com/sap/latest/sap-AnyDB/sap-ibm-pacemaker.html)
+ [DB2 데이터베이스 간 HADR 복제를 설정하는 단계별 절차](https://www.ibm.com/support/pages/step-step-procedure-set-hadr-replication-between-db2-databases)
+ [Db2 HADR Wiki](https://ibm.github.io/db2-hadr-wiki/index.html)

## 추가 정보
<a name="set-up-disaster-recovery-for-sap-on-ibm-db2-on-aws-additional"></a>

이 패턴을 사용하여 Db2 데이터베이스에서 실행되는 SAP 시스템에 대한 재해 복구 시스템을 설정할 수 있습니다. 재해 상황에서 비즈니스는 정의된 Recovery Time Objective(RTO) 및 Recovery Point Objective(RPO) 요구 사항 내에서 업무를 계속할 수 있어야 합니다.
+ **RTO**는 서비스 중단과 서비스 복원 사이의 허용 가능한 최대 지연 시간입니다. 이는 서비스를 이용할 수 없을 때 허용 가능한 기간으로 간주되는 기간을 결정합니다.
+ **RPO**는 마지막 데이터 복구 시점 이후 허용되는 최대 시간입니다. 이에 따라 마지막 복구 시점과 서비스 중단 사이에 허용되는 데이터 손실로 간주되는 범위가 결정됩니다.

HADR과 관련된 자주 묻는 질문은 [SAP note \$11612105-DB6: Db2 고가용성 재해 복구(HADR)에 대한 자주 묻는 질문](https://launchpad.support.sap.com/#/notes/1612105)을 참조하십시오. (이 노트에 액세스하려면 SAP 포털 보안 인증 정보가 필요합니다.)