의 IBM Db2SAP에서 에 대한 재해 복구 설정 AWS - AWS 권장 가이드

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

의 IBM Db2SAP에서 에 대한 재해 복구 설정 AWS

작성자: Ambarish Satarkar(AWS) 및 Debasis Sahoo(AWS)

환경: 프로덕션

기술: 데이터베이스, 운영

워크로드: SAP

AWS 서비스: Amazon EC2, AWS Elastic Disaster Recovery

요약

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

이 패턴은 파일럿 라이트 접근 방식을 사용합니다. 에서 파일럿 라이트 DR을 구현하면 가동 중지 시간을 줄이고 비즈니스 연속성AWS을 유지할 수 있습니다. 파일럿 라이트 접근 방식은 프로덕션 환경과 동기화되는 SAP 시스템 및 대기 Db2 데이터베이스를 AWS포함하여 에서 최소 DR 환경을 설정하는 데 중점을 둡니다.

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

사전 조건 및 제한 사항

사전 조건 

  • Amazon Elastic Compute Cloud(AmazonEC2) SAP 인스턴스에서 실행되는 인스턴스

  • IBM Db2 데이터베이스

  • SAP 제품 가용성 매트릭스(PAM)에서 지원하는 운영 체제

  • 운영 및 스탠바이 데이터베이스 호스트의 서로 다른 물리적 데이터베이스 호스트 이름

  • 리전 간 복제()가 활성화된 각 AWS 리전의 Amazon Simple Storage Service(Amazon S3) 버킷 CRR

제품 버전

  • IBM Db2 데이터베이스 버전 11.5.7 이상

아키텍처

대상 기술 스택

  • Amazon EC2

  • Amazon Simple Storage Service(S3)

  • Amazon Virtual Private Cloud(VPC 피어링)

  • Amazon Route 53

  • IBM Db2 고가용성 재해 복구(HADR)

대상 아키텍처 

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

리전 1을 사용할 수 없게 될 정도의 재해가 발생하는 경우 DR 리전의 스탠바이 데이터베이스가 프로덕션 데이터베이스 역할을 대신합니다. SAP 애플리케이션 서버는 미리 구축하거나 AWS Elastic Disaster Recovery 또는 Amazon Machine Image(AMI)를 사용하여 복구 시간 목표(RTO) 요구 사항을 충족할 수 있습니다. 이 패턴은 를 사용합니다AMI.

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

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

리전 간 복제를 AWS 사용한 의 Db2
  1. 리전 1에서 애플리케이션 서버의 를 생성하고 AMI 리전 2에 복사AMI합니다. 재해 발생 시 AMI를 사용하여 리전 2에서 서버를 시작합니다.

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

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

  4. 리전 1에서는 LOGARCHMETH1db2remote: S3 path로 설정됩니다.

  5. 리전 2에서는 LOGARCHMETH1db2remote: S3 path로 설정됩니다.

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

도구

AWS 서비스

  • Amazon Elastic Compute Cloud(Amazon EC2)는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 필요한 만큼 가상 서버를 시작하고 빠르게 스케일 업하거나 스케일 다운할 수 있습니다.

  • Amazon Route 53은 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.

  • Amazon Simple Storage Service(S3)는 원하는 양의 데이터를 저장, 보호 및 검색하는 데 도움이 되는 클라우드 기반 객체 스토리지 서비스입니다.

  • Amazon Virtual Private Cloud(Amazon VPC)를 사용하면 정의한 가상 네트워크로 AWS 리소스를 시작할 수 있습니다. 이 가상 네트워크는 자체 데이터 센터에서 운영하는 기존 네트워크와 유사하며 확장 가능한 인프라를 사용할 때의 이점이 있습니다AWS. 이 패턴은 VPC 피어링 을 사용합니다.

모범 사례

  • 네트워크는 HADR 복제 모드를 결정하는 데 중요한 역할을 합니다. AWS 리전 간 DR의 경우 Db2 HADR ASYNC 또는 SUPERASYNC 모드를 사용하는 것이 좋습니다. 

  • Db2 의 복제 모드에 대한 자세한 내용은 IBM 설명서를 HADR참조하세요.

  • AWS 관리 콘솔 또는 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 기존 SAP 시스템을 새로 생성할 AMI 수 있습니다. 그런 다음 AMI를 사용하여 기존 SAP 시스템을 복구하거나 복제본을 생성할 수 있습니다.

  • AWS Systems Manager Automation은 EC2 인스턴스 및 기타 AWS 리소스의 일반적인 유지 관리 및 배포 작업에 도움이 될 수 있습니다.

  • AWS 는 에서 인프라 및 애플리케이션을 모니터링하고 관리할 수 있는 여러 네이티브 서비스를 제공합니다AWS. Amazon CloudWatch 및 와 같은 서비스는 각각 기본 인프라 및 API 작업을 모니터링하는 데 사용할 AWS CloudTrail 수 있습니다. 자세한 내용은 SAP의 AWS – Pacemaker 가 HADR 포함된 IBM Db2를 참조하세요.

에픽

작업설명필요한 기술

시스템과 로그를 확인합니다.

  1. SAP Db2 시스템에서 프로덕션이 설정되었는지 확인합니다.

  2. 로그 백업이 켜져 있고 S3 버킷에 로그를 저장하도록 구성되어 있는지 확인합니다. 이는 Db2 파라미터 LOGARCHMETH1으로 확인할 수 있습니다.

  3. 추가 애플리케이션 서버의 AMI 를 생성합니다.

AWS 관리자, SAP Basis 관리자
작업설명필요한 기술

SAP 및 데이터베이스 서버를 생성합니다.

  1. DR 리전의 인프라를 배포하려면 AWS CloudFormation 스크립트를 사용하거나 프로덕션 인스턴스AMI의 를 사용합니다. 파일럿 라이트 접근 방식의 일부로 프로덕션 EC2 인스턴스와 동일한 패밀리에서 더 작은 인스턴스를 사용할 수 있습니다. 예를 들어 프로덕션 인스턴스 유형이 r6i.12xlarge인 경우 해당 r6i.xlarge 인스턴스 유형을 DR 빌드에 사용할 수 있습니다. 하지만 프로덕션 데이터베이스 백업을 복원하려면 DR 인스턴스에 동일한 스토리지 용량을 할당해야 합니다.

  2. 에 대한 Amazon Elastic File System(AmazonEFS) 탑재 지점을 생성하고 기본 시스템에서 복제되도록 설정되어 있는지 /sapmnt/<SID>/확인합니다.

  3. 프로덕션 시스템에서 FULL 데이터베이스 백업(온라인 또는 오프라인)을 가져옵니다. 이 백업을 사용하여 DR 데이터베이스를 구축합니다.

  4. DR 시스템에서 SAP 소프트웨어 프로비저닝 관리자(SWPM) 시스템 복사 메서드를 HA/DR 목적으로 백업/복원과 함께 시스템 복사를 사용하여 DR SAP 시스템을 빌드합니다.

  5. 에서 요청하면 프로덕션에서 가져온 백업을 사용하여 DR에서 데이터베이스를 SWPM복원합니다. DR 데이터베이스는 롤포워드 보류 상태가 됩니다.

롤포워드 보류 상태는 전체 백업이 복원된 후에 기본적으로 설정됩니다. 롤포워드 보류 상태는 데이터베이스를 복원하는 중이며 일부 변경 사항을 적용해야 할 수 있음을 나타냅니다. 자세한 내용은 IBM 설명서를 참조하세요.

SAP 기본 관리자

구성을 확인합니다.

  1. 에 대한 로그 아카이브를 설정하려면 프로덕션 데이터베이스와 DR 데이터베이스HADR가 모두 모든 로그 아카이브 위치에서 로그를 자동으로 검색할 수 있어야 합니다. DR 데이터베이스의 LOGARCHMETH1 파라미터가 프로덕션 데이터베이스의 파라미터와 동일한 위치로 설정되어 있는지 확인합니다. 리전 제한으로 인해 동일한 위치에 액세스할 수 없는 경우 DR 시스템이 기본 시스템에서 자동으로 로그를 가져올 수 있는지 확인합니다.

  2. 데이터베이스 복제 활성화를 위한 TCP/IP 포트를 활성화하려면 다음 두 항목을 추가하여 프로덕션 및 DR 호스트/etc/services에서 를 수정합니다. 코드에서 는 Db2 데이터베이스(예: SID)의 시스템 ID()를 <SID> 나타냅니다PR1.

    <SID>_HADR_1 55001/tcp # DB2 HADR Port1 <SID>_HADR_2 55002/tcp # DB2 HADR Port2

    두 포트 모두 기본 데이터베이스와 스탠바이 데이터베이스 간의 인바운드 및 아웃바운드 트래픽을 허용하는지 확인합니다.

  3. 프로덕션 및 DR 호스트에서 /etc/hosts를 점검하여 프로덕션 호스트와 스탠바이 호스트 모두의 호스트 이름이 올바른 IP 주소를 가리키는지 확인합니다.

AWS 관리자, SAP Basis 관리자

프로덕션 DB에서 DR DB로 복제를 설정합니다(ASYNC모드 사용).

  1. 프로덕션 데이터베이스에서 다음 명령을 실행하여 파라미터를 업데이트합니다.

    db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST1 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid> db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120 db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000 db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240 db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON
  2. DR 데이터베이스에서 다음 명령을 실행하여 파라미터를 업데이트합니다.

    db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_HOST HOST2 db2 UPDATE DB CFG FOR <SID> USING HADR_LOCAL_SVC <SID>_HADR_2 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_HOST HOST1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_SVC <SID>_HADR_1 db2 UPDATE DB CFG FOR <SID> USING HADR_REMOTE_INST db2<sid> db2 UPDATE DB CFG FOR <SID> USING HADR_TIMEOUT 120 db2 UPDATE DB CFG FOR <SID> USING HADR_SYNCMODE ASYNC db2 UPDATE DB CFG FOR <SID> USING HADR_SPOOL_LIMIT 1000 db2 UPDATE DB CFG FOR <SID> USING HADR_PEER_WINDOW 240 db2 UPDATE DB CFG FOR <SID> USING indexrec RESTART logindexbuild ON

    이러한 파라미터는 두 데이터베이스에 HADR관련 정보를 제공하는 데 필요합니다. Db2 데이터베이스에서 HADR는 이전에 설정된 각 파라미터의 값을 기반으로 활성화됩니다. 이러한 파라미터에 대한 자세한 내용은 IBM 설명서 섹션을 참조하세요.

  3. 다음 명령을 사용하여 새로 생성된 대기 데이터베이스에서 HADR 먼저 시작합니다.

    db2 deactivate db <SID> db2 start hadr on db <SID> as standby
  4. 다음 명령을 사용하여 HADR 프로덕션 데이터베이스를 시작합니다.

    db2 deactivate db <SID> db2 start hadr on db <SID> as primary
  5. 프로덕션 및 스탠바이 Db2 데이터베이스가 동기화되어 있고 로그 전달이 진행 중인지 확인합니다.

    HADR 복제 상태를 모니터링하려면 다음 db2pd 명령을 사용합니다.

    db2pd -d <SID> -hadr

    모니터링에 대한 자세한 내용은 IBM 설명서 섹션을 HADR참조하세요.

SAP 기본 관리자
작업설명필요한 기술

DR 테스트를 위한 프로덕션 비즈니스 다운타임을 계획합니다.

DR 장애 조치 시나리오를 테스트하려면 프로덕션 환경에서 필요한 비즈니스 다운타임을 계획해야 합니다.

SAP 기본 관리자

테스트 사용자를 생성합니다.

DR 호스트에서 검증할 수 있는 테스트 사용자(또는 모든 테스트 변경 사항)를 생성하여 DR 장애 조치 후 로그 복제를 확인합니다.

SAP 기본 관리자

콘솔에서 프로덕션 EC2 인스턴스를 중지합니다.

이 단계에서는 재해 시나리오를 모방하기 위해 비정상 종료가 시작됩니다.

AWS 시스템 관리자

요구 사항에 맞게 DR EC2 인스턴스를 확장합니다.

EC2 콘솔에서 DR 리전의 인스턴스 유형을 변경합니다.

  1. 인스턴스 중지: 인스턴스가 실행 중인 경우 인스턴스 유형을 변경하기 전에 인스턴스를 중지해야 합니다. EC2 콘솔에서 인스턴스를 선택하고 중지 를 선택합니다.

  2. 인스턴스 유형 수정: EC2 콘솔에서 인스턴스를 선택하고 작업, 인스턴스 설정, 인스턴스 유형 변경을 선택합니다. 기본 인스턴스와 일치하는 인스턴스 유형을 선택하고 적용을 선택합니다.

  3. 인스턴스 시작: 인스턴스 유형 변경이 완료되면 인스턴스를 선택하고 시작을 선택하여 EC2 콘솔에서 인스턴스를 시작합니다.

  4. Db2 데이터베이스를 삭제하려면 다음 명령을 사용합니다.

    db2start db2 start HADR on db <SID> as standby
SAP 기본 관리자

인계를 시작합니다.

DR 시스템(host2)에서 인계 프로세스를 시작하고 DR 데이터베이스를 기본 데이터베이스로 불러옵니다.

db2 takeover hadr on database <SID> by force

선택적으로 다음 파라미터를 설정하여 인스턴스 유형에 따라 데이터베이스 메모리 할당을 자동으로 조정할 수 있습니다. Db2 데이터베이스에 할당할 메모리 전용 부분에 따라 INSTANCE_MEMORY 값을 결정할 수 있습니다.

db2 update db cfg for <SID> using INSTANCE_MEMORY <FIXED VALUE> IMMEDIATE; db2 get db cfg for <SID> | grep -i DATABASE_MEMORY AUTOMATIC IMMEDIATE; db2 update db cfg for <SID> using self_tuning_mem ON IMMEDIATE;

다음 명령을 사용하여 문제를 확인합니다.

db2 get db cfg for <SID> | grep -i MEMORY db2 get db cfg for <SID> | grep -i self_tuning_mem
SAP 기본 관리자

DR 리전SAP에서 에 대한 애플리케이션 서버를 시작합니다.

프로덕션 시스템으로 AMI 만든 를 사용하여 DR 리전에서 새 추가 애플리케이션 서버를 시작합니다.

SAP 기본 관리자

SAP 애플리케이션을 시작하기 전에 검증을 수행합니다.

  1. /etc/hosts/etc/fstab 항목을 검증합니다.

  2. DR 시스템에 /sapmnt/<SID>/를 마운트합니다.

  3. DR 파일 시스템 /sapmnt/<SID>/가 프로덕션 /sapmnt/<SID>/와 동기화되었는지 확인합니다.

  4. <sid>adm 사용자에 로그인하여 R3trans -d를 실행하고 trans.log 파일의 출력을 확인합니다. trans.log 파일은 R3trans -d 명령을 실행한 위치와 동일한 위치에 생성됩니다.

AWS 관리자, SAP Basis 관리자

DR 시스템에서 SAP 애플리케이션을 시작합니다.

<sid>adm 사용자를 사용하여 DR 시스템에서 SAP 애플리케이션을 시작합니다. Central SAP ABAP SAP Services(ASCS) 서버의 인스턴스 번호를 XX 나타내고 SAP 애플리케이션 서버의 인스턴스 번호를 YY 나타내는 다음 코드를 사용합니다.

sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem
SAP 기본 관리자

SAP 검증을 수행합니다.

이는 증거를 제공하거나 DR 리전으로의 데이터 복제 성공 여부를 확인하기 위한 DR 테스트로 수행됩니다.

테스트 엔지니어
작업설명필요한 기술

프로덕션 SAP 및 데이터베이스 서버를 시작합니다.

콘솔에서 호스팅하는 EC2 인스턴스SAP와 프로덕션 시스템의 데이터베이스를 시작합니다.

SAP 기본 관리자

프로덕션 데이터베이스를 시작하고 를 설정합니다HADR.

프로덕션 시스템(host1)에 로그인하고 다음 명령을 사용하여 DB가 복구 모드에 있는지 확인합니다.

db2start db2 start HADR on db P3V as standby db2 connect to <SID>

HADR 상태가 인지 확인합니다connected. 복제 상태는 peer여야 합니다.

db2pd -d <SID> -hadr

데이터베이스가 일관되지 않고 connectedpeer 상태가 아닌 경우 (host1의) 데이터베이스를 (host2 DR 리전의) 현재 활성 데이터베이스와 동기화하려면 백업 및 복원이 필요할 수 있습니다. 이 경우 host2 DR 리전의 데이터베이스에서 host1 프로덕션 리전의 데이터베이스로 DB 백업을 복원합니다.

SAP 기본 관리자

데이터베이스를 프로덕션 리전으로 페일백합니다.

일반적인 business-as-usual 시나리오에서 이 단계는 예약된 가동 중지 시간에 수행됩니다. DR 시스템에서 실행 중인 애플리케이션이 중지되고 데이터베이스가 프로덕션 리전(리전 1)으로 페일백되어 프로덕션 리전에서 작업이 재개됩니다.

  1. DR 리전의 SAP 애플리케이션 서버에 로그인하고 SAP 애플리케이션을 중지합니다.

  2. DR 시스템에서 /sapmnt/<SID>를 마운트 해제하여 변경 내용이 프로덕션 시스템의 /sapmnt/<SID>에 역복제되도록 합니다.

  3. 프로덕션 리전의 데이터베이스 서버(host1)에 로그인하여 인계를 수행합니다.

    db2 takeover hadr on database <SID>
  4. HADR 상태를 확인합니다. 는 PRIMARYhost1지고 는 StandBy켜져야 HADR_ROLE 합니다host2.

    db2pd -d <SID> -hadr
SAP 기본 관리자

SAP 애플리케이션을 시작하기 전에 검증을 수행합니다.

  1. /etc/hosts/etc/fstab 항목을 검증합니다.

  2. 프로덕션 시스템에 /sapmnt/<SID>/를 마운트합니다.

  3. DR 시스템 /sapmnt/<SID>/와 동기화되어 있는지 확인합니다.

  4. <sid>adm 사용자에 로그인하여 R3trans -d를 실행하고 trans.log 파일의 출력을 확인합니다. trans.log 파일은 R3trans -d 명령을 실행한 위치와 동일한 위치에 생성됩니다.

AWS 관리자, SAP Basis 관리자

SAP 애플리케이션을 시작합니다.

  1. <sid>adm 사용자를 사용하여 프로덕션 시스템에서 SAP 애플리케이션을 시작합니다. 서버의 인스턴스 번호를 XX 나타내고 SAP 애플리케이션 SAP ASCS 서버의 인스턴스 번호를 YY 나타내는 다음 코드를 사용합니다.

    sapconrol -nr XX -function StartService <SID> sapconrol -nr XX -function StartSystem sapconrol -nr YY -function StartService <SID> sapconrol -nr YY -function StartSystem
  2.  애플리케이션 서버를 사용할 수 있는지 확인하려면 SICK 및 SM51 트랜잭션을 사용하여 에 로그인SAP하고 확인을 수행합니다.

SAP 기본 관리자

문제 해결

문제Solution

HADR관련 문제를 해결하기 위한 키 로그 파일 및 명령

  • db2 get db cfg | grep -i hadr

  • db2pd -d sid -hadr

  • Db2diag.log(이 파일은 일반적으로 db2dump 디렉터리 내에 있으며 db2dump 경로는 파라미터 DIAGPATH로 정의됩니다.)

SAP Db2의 HADR 문제 해결을 위한 참고 사항 UDB

SAP 참고 1154013 - DB6: HADR 환경 의 DB 문제를 참조하세요. (이 메모에 액세스하려면 SAP 포털 보안 인증 정보가 필요합니다.)

관련 리소스

추가 정보

이 패턴을 사용하여 Db2 데이터베이스에서 실행되는 시스템에 대한 재해 복구 SAP 시스템을 설정할 수 있습니다. 재해 상황에서 비즈니스는 정의된 복구 시간 목표(RTO) 및 복구 시점 목표(RPO) 요구 사항 내에서 계속할 수 있어야 합니다.

  • RTO 는 서비스 중단과 서비스 복원 사이의 허용되는 최대 지연 시간입니다. 이는 서비스를 이용할 수 없을 때 허용 가능한 기간으로 간주되는 기간을 결정합니다.

  • RPO 는 마지막 데이터 복구 시점 이후 허용되는 최대 시간입니다. 이에 따라 마지막 복구 시점과 서비스 중단 사이에 허용되는 데이터 손실로 간주되는 범위가 결정됩니다.

FAQs 관련 정보는 SAP Db2 고가용성 재해 복구(HADR)FAQ의 참고 #1612105 - DB6:를 HADR참조하세요. (이 메모에 액세스하려면 SAP 포털 보안 인증 정보가 필요합니다.)