주:

• 이 사용지침서에서는 Oracle Cloud에 액세스해야 합니다. 무료 계정에 등록하려면 Oracle Cloud Infrastructure Free Tier 시작하기를 참조하십시오.
• Oracle Cloud Infrastructure 인증서, 테넌시 및 구획에 예제 값을 사용합니다. 실습을 완료할 때 이러한 값을 클라우드 환경과 관련된 값으로 대체하십시오.

OCI 전체 스택 재해 복구를 사용하여 다중 노드 Oracle E-Business Suite에 대한 복구 자동화

소개

OCI Full Stack Disaster Recovery는 애플리케이션 엔지니어링 팀이 자체 재해 복구 기능과 특징을 설계, 작성 및 유지 관리하는 데 사용합니다. 애플리케이션 엔지니어링 팀이 재해 복구를 위한 OCI 소프트웨어 개발 키트(SDK) API를 포함하는 OCI 네이티브 재해 복구 기능을 내장한 경우, 해당 애플리케이션을 Full Stack DR에 네이티브 멤버 리소스로 추가할 수 있습니다.

Oracle E-Business Suite에는 현재 OCI 네이티브 재해 복구 기능 또는 기능이 없으며 Full Stack DR의 네이티브 멤버 리소스가 아닙니다. 그러나 Oracle E-Business Suit 엔지니어링 팀은 OCI 리전에서 EBS를 수동으로 배포하고 복구하는 프로세스를 문서화했습니다. Full Stack DR을 사용하여 수동 프로세스를 자동화할 수 있습니다. 이 문서에서는 페일오버, 스위치오버 및 드릴을 위한 기본 DR 계획에 사용자 정의 계획 그룹 및 단계를 추가하여 수동 복구 프로세스를 자동화하는 방법을 설명합니다.

Oracle Cloud Infrastructure Full Stack Disaster Recovery(OCI Full Stack DR)는 클릭 한 번으로 전 세계 Oracle Cloud Infrastructure(OCI) 리전 간의 컴퓨트, 데이터베이스, 애플리케이션 전환을 통합관리합니다. 고객은 기존 인프라, 데이터베이스 또는 애플리케이션을 재설계하거나 재설계하지 않고도 하나 이상의 비즈니스 시스템을 복구하는 데 필요한 단계를 자동화할 수 있습니다.

Oracle E-Business Suite는 오늘날 진화하는 비즈니스 모델을 지원하고 생산성을 높이며 모던 모바일 사용자의 요구를 충족합니다. 30년의 혁신 역사를 바탕으로 구축된 Oracle E-Business Suite는 새로운 애플리케이션 기능을 제공하고 기존 기능의 기능을 확장하는 동시에 OCI의 모든 이점을 누릴 수 있도록 지원합니다.

일반적으로 대규모 시스템의 일부인 Oracle E-Business Suite

Oracle E-Business Suite는 일반적으로 여러 개의 추가 데이터베이스, OCI 마켓플레이스 애플리케이션 및 OCI 서비스를 모두 단일 단위로 복구해야 하는 보다 복잡한 비즈니스 시스템의 기반입니다. 이 사용지침서에서는 Oracle E-Business Suite를 단순하고 중점적으로 다루기 위해 Oracle E-Business Suite와 관련된 작업만 보여줍니다. 그러나 Oracle E-Business Suite가 DR 보호 그룹 및 DR 계획의 일부인 유일한 응용 프로그램인 것은 매우 드문 일입니다.

Incremental 구현 주의

DR 계획을 생성한 후 DR 보호 그룹에 멤버를 더 추가하거나 삭제하면 두 영역의 보호 그룹에 있는 기존 DR 계획이 새로고침됩니다. 자세한 내용은 재해 복구 계획 새로고침을 참조하십시오.

OCI Full Stack DR은 주어진 비즈니스 시스템의 전체 애플리케이션 스택이 이미 OCI 리전에 배포되었고, 수동 DR이 이미 작동 중인 것으로 입증되었다는 가정 하에 설계되었습니다. 비즈니스 시스템에 Oracle E-Business Suite 이상이 포함된 경우 DR 계획을 생성하기 전에 다른 모든 컴퓨트, 스토리지, 데이터베이스, 애플리케이션 또는 OCI 서비스를 DR 보호 그룹에 추가하십시오.

복구 작동 방식

Oracle E-Business Suite용 복구 솔루션을 사용하려면 복구 작업(예: 페일오버 또는 스위치오버 또는 드릴) 중에 일련의 사용자정의 Bash 스크립트를 실행하기 위해 OCI Full Stack DR이 필요합니다. 이 자습서에서는 Oracle E-Business Suite 애플리케이션 노드를 스크립트 호스팅 및 실행을 위한 제어 노드로 사용합니다.

이 사용지침서에 참조된 스크립트는 Oracle EMEA Cloud Engineering Oracle Apps to OCI 전문팀에서 제공하며 OCI Full Stack Disaster Recovery를 위한 Oracle E-Business Suite 스크립트에서 제공됩니다. 배치의 고유한 요구에 맞게 Bash 스크립트를 약간 수정해야 할 수도 있습니다.

그림 1: Oracle 샘플 GitHub 저장소에서 사용할 수 있는 Oracle E-Business Suite 스크립트

이 자습서에서는 스크립트를 다운로드하는 방법과 이후 단계에서 스크립트를 사용하는 방법에 대해 설명합니다. 이 사용지침서에는 Oracle E-Business Suite 이외의 항목이 포함되어 있지 않으므로 이 사용지침서에서는 Bash 스크립트를 호스팅하기 위해서만 옵션 1을 사용합니다.

주: 일반적인 지침은 다음 스크립트를 제공합니다. 자체 스크립트를 사용하거나 회사 정책 및 보안 요구 사항에 따라 스크립트를 사용자 정의할 수 있습니다.

스크립트 호스팅을 위한 옵션 1

두 영역에서 실행되는 Oracle E-Business Suite 응용 프로그램 서버에 Bash 스크립트를 설치합니다. 이 사용지침서에서는 스크립트를 제어 노드 또는 DR 노드로 설치하는 컴퓨트 인스턴스가 애플리케이션 스택에 있는 하나 이상의 Oracle E-Business Suite 애플리케이션 서버인 경우에도 해당 인스턴스를 참조합니다.

스크립트 호스팅을 위한 옵션 2

특수 제어 노드 또는 DR 노드를 생성하여 모든 Oracle E-Business Suite 스크립트와 다른 애플리케이션 또는 OCI 서비스에 필요한 스크립트를 호스팅합니다.

Oracle E-Business Suite는 사용자 정의 사내 애플리케이션, Oracle Cloud Marketplace 애플리케이션, Oracle Business Analytics 및 기타 데이터베이스, 컴퓨팅 인스턴스 및 자체 개발 애플리케이션을 포함하는 보다 크고 복잡한 비즈니스 시스템의 일부입니다. 이 경우 스크립트를 호스팅할 비즈니스 시스템의 이미 일부인 컴퓨트 인스턴스 중 하나를 선택하면 됩니다. 선택한 컴퓨트 인스턴스는 Oracle Linux가 설치된 모든 것이 될 수 있으며, 애플리케이션 서버 또는 관리 서버와 같은 다른 용도로 사용되는 기존 VM일 가능성이 높습니다.

일반적으로 OCI Full Stack DR은 복구 작업을 자동화하는 데 특별한 관리 서버가 필요하지 않습니다. 하지만 이 경우 특수 관리 서버 역할을 하는 컴퓨트 인스턴스를 생성합니다. 특수 관리 서버는 이 문서 전체에서 제어 노드 또는 DR 노드로 표시됩니다. 제어 노드의 전체 목적은 복구 작업 중에 모든 사용자정의 스크립트가 상주하고 OCI Full Stack DR에 의해 호출될 수 있는 서버 역할을 하는 것입니다.

참고: 이 자습서에서는 사용자정의 Oracle E-Business Suite 애플리케이션 관련 스크립트를 Oracle E-Business Suite 애플리케이션 서버에 저장하는 옵션 1을 사용합니다.

Oracle E-Business Suite 배치 구조

OCI Full Stack DR을 도입하기 전에 먼저 OCI 리전 전반의 재해 복구(DR)를 위해 Oracle E-Business Suite를 배포해야 합니다. 복구를 수행하기 위한 수동 단계는 OCI Full Stack DR을 사용하여 복구 프로세스를 자동화하기 전에 테스트하고 올바르게 작동하는 것이 매우 중요합니다.

OCI 리전에 DR용 Oracle E-Business Suite를 배포할 때 아래와 같은 두 가지 참조 아키텍처 중 하나를 따를 수 있습니다. 두 참조 아키텍처 모두 2개의 OCI 리전에 분산된 중복 리소스가 있는 다중 계층 토폴로지를 보여줍니다.

다중 인스턴스 데이터베이스는 Oracle RAC(Oracle Real Application Clusters)로 구축되며 Oracle Data Guard를 사용하여 두 OCI 리전에서 데이터베이스를 동기화 상태로 유지합니다.

Oracle Base Database Service를 사용하는 Oracle E-Business Suite용 참조 구조

Oracle E-Business Suite에서 Oracle Base Database Service를 사용하는 경우 이 배치 구조를 선택합니다. Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2875417.1)에 설명된 대로 2개의 OCI 리전에서 DR을 위해 Oracle E-Business Suite를 배포해야 합니다. 그림 1에 표시된 그림은 문서 ID 2875417.1에서 얻었습니다.

그림 1: OCI Base Database를 사용하는 Oracle E-Business Suite DR 배포 아키텍처(자세한 내용은 문서 ID 2875417.1 참조)

Oracle Exadata Database Service on Dedicated Infrastructure를 사용하는 Oracle E-Business Suite용 참조 아키텍처

Oracle E-Business Suite에서 Oracle Exadata Database Service on Dedicated Infrastructure를 사용하는 경우 이 배치 구조를 선택합니다. Oracle E-Business Suite는 Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Exadata Database Service on Dedicated Infrastructure(문서 ID 2919723.1)에 설명된 대로 두 OCI 리전에서 DR을 위해 배포해야 합니다. 그림 1에 표시된 그림은 문서 ID 2919723.1에서 얻었습니다.

그림 2: OCI Exadata Database를 사용하는 Oracle E-Business Suite DR 배포 아키텍처(자세한 내용은 문서 ID 2919723.1 참조)

논리 호스트 이름과 물리적 호스트 이름의 차이점

Oracle E-Business Suite에서는 응용 프로그램 서버에 논리 호스트 이름을 사용하고 데이터베이스에 물리적 호스트 이름을 사용할 것을 강력히 권장합니다. Both Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2875417.1) and Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2919723.1) written by Oracle E-Business Suite engineering require that the application tier uses logical hostnames while the database tier uses physical hostnames.

OCI Full Stack DR은 논리적 또는 물리적 호스트 이름 사용 여부에 대한 요구사항이 없지만 문제가 발생할 경우 Oracle E-Business Suite의 지원을 보장하기 위해 Oracle E-Business Suite 요구사항을 따르는 것이 좋습니다. 일부 고객은 응용 프로그램 및 데이터베이스 계층 모두에 논리 호스트 이름을 사용합니다. 이 솔루션과 함께 제공되는 스크립트는 응용 프로그램 계층 및 물리적 호스트 이름 데이터베이스 계층에 대한 논리 호스트 이름과 함께 사용하도록 설계되었습니다. 다운로드 지침은 작업 1.2를 참조하십시오.

OCI Full Stack DR 배포 아키텍처

다음 그림은 OCI 전체 스택 DR에 대한 각 DRPG(DR Protection Group)에 멤버로 추가된 컴퓨트 리소스를 보여줍니다. 이러한 구성 요소는 OCI Full Stack DR이 Oracle E-Business Suite 애플리케이션 외부에서 관리할 수 있는 다양한 구성 요소를 나타냅니다.

OCI Full Stack DR은 OCI Compute, OCI Block Storage, OCI File Storage, Oracle 데이터베이스, OCI Load Balancer, Oracle Cloud Infrastructure Kubernetes Engine(OKE) 클러스터 및 기타 여러 리소스를 복구하는 동안 처리할 수 있는 자동화 기능이 내장되어 있지만, Oracle E-Business Suite 자체를 위한 자동화 기능이 내장되어 있지 않습니다. Oracle E-Business Suite 복구는 이 자습서 전용의 GitHub 저장소에서 다운로드할 수 있는 일련의 Bash 스크립트로 제어됩니다. 스크립트 배치 및 제어를 위해 다음 옵션 중 하나를 수행하여 선택한 컴퓨트 인스턴스에 Bash 스크립트를 설치해야 합니다.

옵션 1: Oracle Base Database Service를 사용하여 Oracle E-Business Suite에 대한 복구 자동화

이 배포 아키텍처는 일반적이지 않으며 Oracle E-Business Suite가 OCI Full Stack DR을 통해 복구되는 유일한 애플리케이션인 매우 드문 상황에 맞게 고안되었습니다. 이 경우 Oracle E-Business Suite 애플리케이션 노드에서 사용자정의 스크립트를 호스트합니다.

그림 3: OCI Base Database 서비스를 사용하는 Full Stack DR 배포 아키텍처

옵션 2: Oracle Exadata Database Service on Dedicated Infrastructure를 사용하여 Oracle E-Business Suite에 대한 복구 자동화

그림 4에 표시된 단순 배포 아키텍처는 Oracle E-Business Suite의 보다 일반적인 배포의 예로, 많은 서비스와 애플리케이션을 함께 복구해야 하는 더 크고 복잡한 애플리케이션 스택의 한 구성 요소일 뿐입니다. 대부분의 비즈니스 시스템은 다음 이미지에 표시된 가상 시스템보다 훨씬 복잡하며 일반적으로 추가 데이터베이스, 기타 Oracle 및/또는 비 Oracle 애플리케이션과 OIC, ODI, OHS, OCI IAM 등의 기타 OCI 서비스를 포함합니다.

그림 4: Oracle Exadata Database Service on Dedicated Infrastructure를 사용하는 전체 스택 DR 배포 아키텍처

자습서 전체의 정의 및 가정

영역

기본 및 대기 롤은 영역 자체가 아니라 OCI 전체 스택 DR 보호 그룹의 기능입니다. 영역은 하나의 애플리케이션 스택에 대한 기본으로 작동할 수 있으며 완전히 다른 애플리케이션 스택에 대한 대기로도 작동합니다. 기본 및 대기 롤은 유동적입니다.

이 자습서에서는 피닉스에서 실행되는 Oracle E-Business Suite 애플리케이션 스택과 애슈번에서 실행되는 모든 대기 리소스부터 시작합니다. 이 두 리전은 예시일 뿐이며, 애플리케이션 스택을 지원하는 OCI 리전 2개는 실제로 사용될 수 있습니다.

• 지역 1은 피닉스입니다.

  • 피닉스는 기본 영역으로 시작됩니다.
  • 피닉스는 다음과 같은 이유로 기본 영역으로 시작합니다.
    • Oracle E-Business Suite 응용 프로그램이 피닉스에서 실행 중입니다.
    • Oracle E-Business Suite rsync cron 작업은 피닉스의 Oracle E-Business Suite 애플리케이션 서버(VM)에 있는 /u01의 데이터를 애슈번에서 실행되는 애플리케이션 서버로 복사합니다.
    • 피닉스의 데이터베이스에는 Oracle Data Guard 기본 롤이 있습니다.
  • 이후 작업에서 switchover를 수행하라는 지시를 받은 후에는 결국 Phoenix가 대기 데이터베이스가 됩니다.

• 지역 2는 애슈번입니다.

  • 애슈번은 대기 지역으로 시작됩니다.
  • 애슈번은 다음과 같은 이유로 대기 영역으로 시작됩니다.
    • Oracle E-Business Suite 대기 애플리케이션 서버(VM)가 애슈번에서 실행 중입니다.
    • Oracle E-Business Suite 애플리케이션이 애슈번에서 실행되고 있지 않습니다.
    • /u01의 데이터는 피닉스에서 애슈번의 VM으로 복사됩니다.
    • 애슈번의 데이터베이스에는 Oracle Data Guard 대기 롤이 있습니다.
  • 애슈번은 이후 작업에서 전환을 수행하라는 지시를 받은 후 최종적으로 기본이 됩니다.

구획

Oracle E-Business Suite 및 OCI Full Stack DR을 IT 거버넌스에 대한 표준 내에서 작동하는 모든 구획 체계로 자유롭게 구성할 수 있습니다. 애플리케이션을 자체 개별 구획으로 구성한 다음 모든 DR 보호 그룹을 하나의 구획으로 구성하여 완전히 다른 비즈니스 시스템을 한 눈에 볼 수 있습니다.

• 모든 DR 보호 그룹을 애플리케이션 이외의 단일 구획으로 구성하면 IT 직원이 완전히 다른 여러 비즈니스 시스템에 대한 DR 계획을 쉽게 찾고 실행할 수 있습니다.
• 모든 DR 보호 그룹에 대해 하나의 구획을 사용하면 인적 오류를 제거하고 DR 계획을 찾아 실행할 수 있는 속도를 높일 수 있습니다.
  • Oracle E-Business Suite용 컴파트먼트(ebstesting). 이 자습서에서는 Oracle E-Business Suite와 관련된 Oracle E-Business Suite 자체, 스토리지, 스토리지 버킷, 컴퓨트 및 데이터베이스의 컴파트먼트가 ebstesting입니다.
  • OCI Full Stack DR myprojects용 컴파트먼트입니다. 이 자습서에서는 OCI Full Stack DR 보호 그룹 및 계획에 대한 컴파트먼트가 myprojects입니다.

목표

이 자습서에서는 OCI Full Stack DR을 사용하여 Oracle E-Business Suite의 복구를 자동화하는 방법에 대해 설명합니다.

주: 먼저 지역 1(피닉스) 및 지역 2(애슈번)로 시작합니다. 프로덕션 Oracle E-Business Suite 애플리케이션은 리전 1에서 실행되고 DR은 리전에서 구성됩니다. 이는 배포 시 다른 OCI 리전을 사용하는 실제 리전 name.If이 아닌 리전 1 및 리전 2를 지칭하는 자습서 전반에 걸쳐서 매우 중요합니다. 그런 다음 해당 프로덕션 및 DR 리전을 지칭해야 합니다.

1. 작업 1: OCI 리전에 DR용 Oracle E-Business Suite를 배포합니다.

   1. 2개의 OCI 리전에 걸쳐 DR용 Oracle E-Business Suite를 수동으로 설치하고 배포할 수 있습니다.
   2. 원하는 영역 1에서 영역 2까지의 모든 Recovery 단계를 수동으로 테스트합니다.
   3. 원하는 영역 2에서 영역 1까지의 모든 Recovery 단계를 수동으로 테스트합니다.

2. 작업 2: OCI Full Stack DR 준비

   1. Full Stack DR에 대한 OCI IAM 정책을 설정합니다.
   2. 다른 OCI 서비스에 대한 OCI IAM 정책을 설정합니다.
   3. Oracle E-Business Suite 애플리케이션 서버에 사용자정의 Oracle E-Business Suite 스크립트를 다운로드하여 설치합니다.
   4. Oracle E-Business Suite 애플리케이션 서버가 스크립트와 명령을 실행할 수 있는지 확인합니다.
   5. Oracle E-Business Suite 데이터베이스에 대한 저장소 암호를 생성합니다.
   6. 로그에 대한 오브젝트 스토리지 버킷을 생성합니다.

3. 작업 3: DR 보호 그룹 만들기 및 연관

4. 작업 4: Oracle E-Business Suite 데이터베이스 및 컴퓨트 멤버를 영역 1 및 영역 2 DR 보호 그룹에 추가합니다.

5. 작업 5: 영역 2(애슈번)에서 DR 계획을 생성합니다.

   1. 전환 계획을 생성합니다.
   2. 페일오버 계획 만들기
   3. Startdrill 계획을 생성합니다.

6. 작업 6: 영역 2(애슈번)에서 DR 계획을 사용자 정의합니다.

7. 작업 7: 영역 2(Ashburn)에서 switchover 계획을 실행합니다.

8. 작업 8: 리전 1(피닉스)에서 기본 DR 계획을 생성하고 리전 1(피닉스)에서 DR 계획을 사용자 정의합니다.

   1. switchover 계획을 생성하고 리전 1(피닉스)에서 switchover 계획을 커스터마이즈합니다.
   2. 영역 1(피닉스)에서 복구 계획을 생성하고 복구 계획을 사용자정의합니다.
   3. Startdrill Plan을 생성하고 지역 1(피닉스)에서 Startdrill Plan을 커스터마이즈합니다.

필요 조건

Oracle E-Business Suite는 OCI Full Stack DR 작업을 시작하기 전에 두 리전에서 재해 복구를 위해 배포해야 합니다. 이 내용은 작업 1에서 다룹니다.

작업 1: Disaster Recovery를 위한 Oracle E-Business Suite 배치

OCI 전체 스택 DR은 이 작업의 어떤 부분에도 포함되지 않습니다.

OCI Full Stack DR 작업을 시작하기 전에 두 개의 서로 다른 MOS(My Oracle Support) 지식 문서(KM 노트) 중 하나를 사용하여 OCI 리전 전반에서 재해 복구를 위해 Oracle E-Business Suite를 배포해야 합니다.

또한 Oracle E-Business Suite 복구에 필요한 사용자정의 스크립트/자동화와 함께 KM 참고 사항에 설명된 수동 단계가 OCI Full Stack DR 작업을 시작하기 전에 완전히 테스트되었다는 것도 매우 중요합니다.

Oracle E-Business Suite는 현재 Oracle Base Database Service 및 Oracle Exadata Database Service on Dedicated Infrastructure 서비스를 지원합니다. Oracle Autonomous Database 서비스는 현재 Oracle E-Business Suite에서 지원되지 않습니다. 다음 KM 참고 사항 중 하나 또는 다른 하나에 있는 지침을 따릅니다.

• 문서 ID 2875417.1: BaseDB를 사용하여 DR용 Oracle E-Business Suite 배포

• 문서 ID 2919723.1: ExaDB-D를 사용하여 DR용 Oracle E-Business Suite 배포

작업 2: OCI 전체 스택 DR에 대한 테넌시 준비

OCI 전체 스택 DR은 이 작업의 어떤 부분에도 포함되지 않습니다. 다음 단계에서는 OCI Full Stack DR을 통한 자동 복구를 위해 테넌시, 컴파트먼트, OCI 서비스 및 Oracle E-Business Suite를 준비합니다. 이 절에 설명된 대부분의 작업은 Prerequisites for Full Stack Disaster Recovery에서 설명합니다.

작업 2.1: OCI Full Stack DR에 대한 OCI IAM 정책 설정

다음 문서에 설명된 대로 OCI Full Stack DR에 필요한 OCI IAM 정책을 구성합니다.

• 전체 스택 재해 복구 정책.
• 전체 스택 재해 복구에 필요한 IAM(ID 및 액세스 관리) 정책 구성

작업 2.2: OCI Full Stack DR이 관리하는 기타 서비스에 대한 OCI IAM 정책 설정

OCI Full Stack DR은 컴퓨팅, 네트워킹, 스토리지, 볼트, 데이터베이스 및 기타 서비스와 같은 기타 주요 OCI 서비스를 제어 및 관리할 수 있어야 합니다. 다음 문서에 설명된 대로 다른 서비스에 대해 필요한 OCI IAM 정책을 구성합니다.

• 전체 스택 재해 복구를 통해 관리되는 기타 서비스에 대한 정책.

작업 2.3: Oracle E-Business Suite Application Server에서 Custom Oracle E-Business SuiteScripts 다운로드 및 설치

OCI Full Stack DR에는 OCI Infrastructure as a Service(IaaS) 및 Platform as a Service(PaaS) 리소스에 대한 복구를 통합관리하기 위한 인텔리전스가 내장되어 있습니다. Oracle E-Business Suite는 현재 자체 내장된 재해 복구를 배포하거나 관리할 수 있는 OCI 네이티브 재해 복구 API를 제공하지 않으므로 OCI Full Stack DR에는 Oracle E-Business Suite에 대한 복구를 통합관리하기 위한 내장 인텔리전스가 없습니다.

그러나 OCI Full Stack DR은 이 자습서 뒷부분에서 생성된 기본 DR 계획에 사용자 정의 DR 계획 그룹 및 단계를 추가하여 Oracle E-Business Suite에 대한 복구를 통합관리할 수 있습니다. 이 자습서의 1부에서 설명한 것처럼 사용자 정의 단계는 Oracle E-Business Suite를 복구하는 데 필요한 다양한 작업을 수행하는 일련의 사용자 정의 스크립트를 호출합니다. 스크립트를 다운로드하여 두 영역의 Oracle E-Business Suite 애플리케이션 서버에 있는 모든 컴퓨트 인스턴스에 설치해야 합니다.

1. OCI Full Stack Disaster Recovery용 Oracle E-Business Suite 스크립트에서 Oracle E-Business Suite 스크립트를 다운로드하세요.
2. 리전 1의 각 Oracle E-Business Suite Application Server에 있는 임의의 디렉토리에 스크립트를 복사합니다.
3. 리전 2에 있는 각 Oracle E-Business Suite Application Server의 동일한 디렉토리 위치에 스크립트를 복사합니다.
4. 파일은 oracle 유저가 소유해야 합니다.
5. 파일이 실행 가능한지 확인합니다.

작업 2.4: Oracle E-Business Suite 응용 프로그램 서버에서 스크립트 및 명령을 실행할 수 있는지 확인

OCI Full Stack DR은 Oracle E-Business Suite 애플리케이션 서버에 다운로드된 Oracle E-Business Suite 스크립트를 실행해야 합니다. OCI Full Stack DR은 각 컴퓨트 인스턴스에서 Oracle Cloud Agent를 사용하여 스크립트를 실행합니다. 두 리전에서 Oracle E-Business Suite 애플리케이션 서버로 사용되는 모든 컴퓨트 인스턴스는 Oracle Cloud 에이전트를 사용하여 OCI 콘솔을 통해 명령을 실행할 수 있어야 합니다.

자세한 내용은 Pull Stack Disaster Recovery를 위한 컴퓨트 인스턴스 준비를 참조하십시오. 관리자 권한이 있는 명령 실행에 대한 지침에 특히 주의하십시오.

OCI 콘솔에서 명령을 실행할 수 있는지 검증

주: 이 작업을 수행하면 Oracle Could Agent가 명령을 실행할 수 있습니다. Full Stack DR이 Oracle Cloud Agent를 통해 명령을 실행할 수 있도록 적절한 정책이 마련되어 있는지 검증하지 않습니다. 이 내용은 자습서에서 영역 2의 스위치오버 DR 계획을 검증하는 방법에 대해 설명할 때 이후 단계에서 분명해집니다.

인스턴스화된 컴퓨트의 Run 명령 기능을 사용하여 Oracle Cloud Agent가 명령을 실행할 수 있는지 검증합니다. 다음 이미지는 OCI 콘솔의 컴퓨트 인스턴스에 대한 세부정보 페이지에서 Run 명령을 보여줍니다.

1. 실행 명령을 선택합니다.
2. Create command를 선택하고 유효한 Linux 명령(예: date)을 입력합니다. 명령을 실행하기 전에 시간 초과 값을 3분과 같이 적당한 값으로 변경합니다.

그림 2.4.1.1: OCI 콘솔에서 명령을 실행합니다.

작업 2.5: Oracle E-Business Suite 데이터베이스에 대한 OCI 저장소 암호 생성

OCI Full Stack DR에는 데이터베이스 sys 비밀번호가 필요하므로 페일오버 및 스위치오버 중에 Oracle Data Guard를 자동으로 트리거할 수 있습니다. 여기에 설명된 대로 두 영역의 저장소 암호에 데이터베이스 sys 비밀번호를 추가합니다. Preparing Oracle Databases for Full Stack Disaster Recovery.

작업 2.6: 로그에 대한 OCI 오브젝트 스토리지 버킷 생성

주: 기존 DR 보호 그룹에 Oracle E-Business Suite를 추가하는 경우 작업 2.3을 완전히 건너뜁니다.

기본 및 대기 영역에서 OCI 오브젝트 스토리지 버킷을 생성하여 복구 작업 중 OCI 전체 스택 DR에 의해 생성된 로그를 저장합니다(여기서 설명됨: 작업 로그에 대한 로그 위치 준비).

작업 2.6.1: OCI Object Storage로 이동

먼저 그림 2-1과 같이 오브젝트 스토리지 및 아카이브 스토리지로 이동합니다.

1. 브라우저 컨텍스트가 region 1(Phoenix)로 설정되어 있는지 확인합니다.
2. Storage를 누릅니다.
3. 버킷을 누릅니다.

그림 2.6.1.1: 오브젝트 스토리지로 이동합니다.

작업 2.6.2: 리전 1과 2에 OCI Object Storage 버킷 생성

리전 1에서 OCI Object Storage 버킷을 생성합니다. 그런 다음 영역 2에 동일한 스토리지 버킷을 생성합니다. 버킷은 이후 작업에서 영역 1 및 2의 DR 보호 그룹에 지정됩니다.

1. Oracle E-Business Suite 관련 리소스를 포함하는 컴파트먼트를 선택합니다. 구획은 지역마다 다를 수 있습니다.
2. 버킷 생성을 누릅니다.
3. 버킷에 제공되는 애플리케이션과 목적을 쉽게 식별할 수 있는 의미 있는 이름을 제공하십시오. 이름의 일부로 지역을 포함할 이유가 없습니다. 예를 들어, 이 이름은 Oracle E-Business Suite에 대한 DR 작업과 관련된 OCI Full Stack DR 로그에 사용됨을 나타냅니다.
4. 계층 및 암호화에 대한 기본값을 사용합니다.
5. 버킷을 생성하려면 생성을 누릅니다.

그림 2.6.2.1: 영역 1 및 2에 오브젝트 스토리지 버킷 생성

작업 3: DR 보호 그룹 만들기 및 연관

이 작업은 Full Stack DR을 포함하는 첫번째 작업입니다. 이 애플리케이션 스택에 대한 보호 그룹이 아직 존재하지 않을 경우 영역 1 및 영역 2에 DR 보호 그룹을 생성합니다.

주: Oracle E-Business Suite가 기존 DR 보호 그룹에 추가되는 경우 작업 3을 완전히 건너뜁니다.

이 작업은 Oracle E-Business Suite를 포함하는 애플리케이션 스택에 대한 OCI Full Stack DR을 구성하는 첫 번째 단계를 시작합니다. DR 보호 그룹은 OCI Full Stack DR에 OCI IaaS 및 PaaS 서비스가 단일 애플리케이션 스택의 일부이고, 두 리전이 비즈니스 시스템의 기본 및 대기로 사용될 것임을 알립니다. DR 보호 그룹은 다른 모든 것이 구축되는 기반을 형성합니다.

두 리전의 애플리케이션 스택에 속하는 모든 OCI IaaS 및 PaaS 리소스가 태스크 4의 일부로 추가됩니다.

참고: 이 자습서에는 Oracle E-Business Suite만 포함되지만, DR 보호 그룹에는 일반적으로 다양한 Oracle 및 비 Oracle 애플리케이션에 대한 OCI IaaS 및 PaaS 서비스와 Oracle E-Business Suite에 필요한 서비스가 포함됩니다.

작업 3.1: Standby Region 2(Ashburn)에서 보호 그룹 생성

먼저 영역 2에 연관되지 않은 DR 보호 그룹을 만듭니다. standby 영역에서 보호 그룹을 생성할 필요가 없으며, 이 프로세스는 region 2에서 시작하여 조금 더 나아집니다.

작업 3.1.1: DR 보호 그룹으로 이동

먼저 그림 3.1.1과 같이 DR 보호 그룹(OCI Full Stack DR)으로 이동합니다.

1. OCI 지역 컨텍스트가 지역 2(애슈번)로 설정되어 있는지 확인합니다.
2. 마이그레이션 및 재해 복구를 누릅니다.
3. DR 보호 그룹을 누릅니다.

그림 3.1.1: DR 보호 그룹으로 이동합니다.

작업 3.1.2: 보호 그룹 만들기

그림 3-1-2와 같이 영역 2에 기본 DRPG(DR 보호 그룹)를 만듭니다. 피어, 롤 및 멤버는 이후 단계에서 지정됩니다.

1. DRPG를 생성할 컴파트먼트를 선택합니다. Oracle E-Business Suite 리소스가 존재하는 컴파트먼트 또는 프로젝트와 관련된 다른 컴파트먼트일 수 있습니다.
2. DR 보호 그룹 만들기를 선택하여 보호 그룹을 만들 매개변수를 입력할 대화 상자를 엽니다.

그림 3.1.2: 영역 2에서 DR 보호 그룹 생성을 시작합니다.

작업 3.1.3: 보호 그룹을 만드는 데 필요한 매개변수 추가

그림 3.1.3과 같이 로그에 대한 이름과 OCI Object Storage 버킷을 추가합니다.

1. DRGP에 대해 의미 있고 간단한 이름을 사용합니다. 이 예에서는 비즈니스 시스템 및 영역의 이름을 보여줍니다.
2. 영역 2에서 DRPG를 생성할 컴파트먼트를 선택합니다.
3. 영역 2에 대해 작업 2에서 생성된 오브젝트 스토리지 버킷을 선택합니다. 다른 컴파트먼트에 버킷을 생성한 경우 컴파트먼트를 변경해야 할 수 있습니다.

추가 매개변수를 입력하지 마십시오. 대화상자의 맨 아래에 있는 생성을 누릅니다(여기에 표시되지 않음).

그림 3.1.3: 영역 2에서 DR 보호 그룹을 생성하는 데 필요한 매개변수

보호 그룹 생성 후 확인해야 할 사항

첫 번째 DR 보호 그룹은 그림 3-2.3과 같이 만들어집니다. 역할 및 피어 정보는 태스크 3.4의 일부로 지정됩니다.

그림 3.1.4: 영역 2에 새로 생성된 DR 보호 그룹 표시

작업 3.2: 기본 영역 1(피닉스)에서 보호 그룹 만들기

영역 1에 보호 그룹을 생성합니다. 이후 작업에서는 이 영역의 애플리케이션 스택에 속하는 모든 OCI 리소스를 추가합니다. 이것이 OCI Full Stack DR이 이 지역의 비즈니스 시스템에 포함되는 자산이 무엇인지 파악하는 방법입니다.

작업 3.2.1: 보호 그룹 만들기

그림 3.2.1과 같이 영역 1에서 기본 DRPG(DR 보호 그룹)를 만듭니다. 피어, 롤 및 멤버는 이후 단계에서 지정됩니다.

1. OCI 지역 컨텍스트를 지역 1로 변경합니다.
2. DRPG를 생성할 컴파트먼트를 선택합니다. 일반적으로 사람들은 영역 2에서 DRPG를 생성하는 데 사용된 것과 동일한 구획을 선택합니다.
3. DR 보호 그룹 생성을 선택하여 보호 그룹을 생성할 매개변수를 입력할 대화 상자를 엽니다.

그림 3.2.1: 영역 1에서 DR 보호 그룹 생성을 시작합니다.

작업 3.2.2: 보호 그룹을 만드는 데 필요한 매개변수 추가

그림 3-5와 같이 로그에 대한 이름 및 오브젝트 스토리지 버킷을 추가합니다.

1. DR PRotection 그룹에 대해 의미 있고 간단한 이름을 사용합니다. 이 예에서는 비즈니스 시스템 및 영역의 이름을 보여줍니다.
2. 영역 1에서 DRPG를 생성할 컴파트먼트를 선택합니다. 일반적으로 두 지역에서 동일한 구획을 사용합니다.
3. 영역 1에 대해 작업 2에서 생성된 오브젝트 스토리지 버킷을 선택합니다. 다른 컴파트먼트에 버킷을 생성한 경우 컴파트먼트를 변경해야 할 수 있습니다.

그림 3.2.2: 영역 1에서 DR 보호 그룹을 생성하는 데 필요한 매개변수

보호 그룹 생성 후 확인해야 할 사항

두번째 DR 보호 그룹은 그림 3.2.3과 같이 만들어집니다. 역할 및 피어 정보는 태스크 3.3의 일부로 지정됩니다.

그림 3.2.3: 영역 2에 새로 생성된 DR 보호 그룹 표시

작업 3.3: 영역 1 및 영역 2에서 보호 그룹 연관

각 지역의 DRPG를 서로의 동료로 연결하고 기본 및 대기 롤을 할당합니다. 이렇게 하면 OCI Full Stack DR이 Oracle E-Business Suite 복구를 위해 어떤 두 리전이 함께 작동하는지 알 수 있습니다. 기본 및 대기 롤은 모든 DR 작업/DR 계획 실행의 일부로 OCI Full Stack DR에 의해 자동으로 변경됩니다. 이 작업에서 DRPG에 초기 롤이 지정된 후에는 언제든지 롤을 수동으로 관리할 필요가 없습니다.

작업 3.3.1: 연관 시작

1. OCI 지역 컨텍스트가 지역 1(피닉스)로 설정되어 있는지 확인합니다.
2. 프로세스를 시작하려면 연결을 누릅니다.

그림 3.3.1: DRPG 연관 시작

작업 3.3.2: 영역 1 및 영역 2에서 보호 그룹 연관

그림 3.3.2와 같이 매개변수를 제공합니다.

1. 기본 역할을 선택하십시오. OCI 전체 스택 DR은 대기 롤을 영역 2에 자동으로 지정합니다.
2. 다른 DRPG가 생성된 지역 2(피닉스)를 선택합니다.
3. 생성된 피어 DRPG를 선택합니다.

그림 3.3.2: DRPG를 연결하는 데 필요한 매개변수

연결 완료 후 확인해야 할 사항:

OCI Full Stack DR은 연결 완료 후 그림 3.3.3과 같이 표시됩니다.

1. 현재 기본 피어 DRPG는 피닉스(지역 1)입니다.
2. 현재 대기 피어 DRPG는 애슈번(지역 2)입니다.

그림 3.3.3: 개별 DRPG 관점의 피어 관계 표시

그림 3.4.3.2과 같이 모든 DR 보호 그룹을 보여주는 전역적 관점에서 컨텍스트/뷰가 표시될 때마다 동일한 정보를 찾을 수 있습니다.

1. 현재 기본 피어 DRPG는 피닉스(지역 1)입니다.
2. 현재 대기 피어 DRPG는 애슈번(지역 2)입니다.

그림 3.4.3.2: 전역 DRPG 관점에서 피어 관계를 보여줍니다.

작업 4: 영역 1 및 영역 2 DR 보호 그룹에 Oracle E-Business Suite 멤버 추가

데이터베이스 및 비이동 Oracle E-Business Suite 애플리케이션 서버를 두 영역 모두에서 DRPG(DR 보호 그룹)의 멤버로 추가합니다. 비이동 컴퓨트는 영역 1에 존재하는 Oracle E-Business Suite 애플리케이션 서버가 영역 2에서 실행되거나 시작되지 않음을 의미합니다. 비이동 컴퓨트용 부트 볼륨은 OCI Storage 복제를 사용하여 영역 2로 복제되지 않으며, DR 보호 그룹의 멤버로 추가되지 않습니다.

이 사용지침서에서는 Oracle E-Business Suite와 관련된 단계만 표시하지만 Oracle E-Business Suite와 함께 복구해야 하는 추가 OCI IaaS 및 PaaS 서비스를 추가할 수도 있습니다. 예를 들어, Oracle E-Business Suite 에코시스템의 일부인 다른 내부 또는 Oracle 애플리케이션과 연관된 다른 이동 컴퓨팅, 비이동 컴퓨팅, 데이터베이스, 로드 밸런서, 파일 시스템, 블록 스토리지 또는 객체 스토리지가 있을 수 있습니다.

주: 이 작업은 기존 DR 보호 그룹에 멤버를 추가할 때 두 영역의 기존 DR 계획을 새로 고칩니다. 자세한 내용은 재해 복구 계획 새로고침을 참조하십시오.

작업 4.1: DR 보호 그룹에 멤버 리소스 추가(피닉스)

영역 1에서 다음 리소스를 기본 DRPG의 멤버로 추가합니다.

1. 두 개의 비이동 Oracle E-Business Suite 애플리케이션 서버(Oracle E-Business Suite 설치 및 실행 중)
2. Oracle E-Business Suite용 Oracle RAC 데이터베이스(Oracle Data Guard 기본 피어)입니다.

작업 4.1.1: 기본 DR 보호 그룹으로 이동

그림 4.1.1과 같이 영역 1의 DR 보호 그룹으로 이동합니다.

1. OCI 리전 컨텍스트가 리전 1(피닉스)인지 확인합니다.
2. 영역 1에서 DR 보호 그룹을 선택합니다.

그림 4.1.1: 영역 1에서 DR 보호 그룹으로 이동합니다.

작업 4.1.2: Oracle E-Business Suite Application Server 1 추가

먼저 멤버 추가 대화상자를 열어 첫번째 애플리케이션 서버를 추가합니다.

1. 멤버를 누릅니다.
2. 구성원 추가을 누릅니다.

그림 4.1.2.1: [멤버 추가] 대화상자를 엽니다.

그림 4.1.2.2과 같이 영역 1에서 응용 프로그램 서버 1을 선택합니다. 블록 볼륨 그룹은 비이동 인스턴스이므로 블록 볼륨 그룹을 추가하거나 네트워크 등록 정보를 지정할 필요가 없습니다.

1. 컴퓨트를 리소스 유형으로 선택합니다.
2. Oracle E-Business Suite 애플리케이션 서버가 포함된 컴파트먼트를 선택하고 애플리케이션 서버 1로 지정한 컴퓨트 인스턴스를 선택합니다.
3. 비이동 인스턴스를 선택합니다. 이를 통해 OCI Full Stack DR은 DR 작업 중 대기 영역에서 복제된 가상 머신을 실행하려고 시도하지 않아야 함을 알립니다.
4. 추가를 눌러 DRPG에 컴퓨트 인스턴스를 추가합니다(표시되지 않음).

그림 4.1.2.2: 응용 프로그램 서버 1에 대한 매개변수를 지정합니다.

작업 4.1.3: Oracle E-Business Suite Application Server 2 추가

1. 구성원 추가을 누릅니다.

   
   그림 4.1.3.1: [멤버 추가] 대화상자를 엽니다.

그림 4.1.3.2과 같이 영역 1에서 응용 프로그램 서버 2를 선택합니다. 블록 볼륨 그룹은 비이동 인스턴스이므로 블록 볼륨 그룹을 추가하거나 네트워크 등록 정보를 지정할 필요가 없습니다.

1. 컴퓨트를 리소스 유형으로 선택합니다.
2. Oracle E-Business Suite 애플리케이션 서버가 포함된 컴파트먼트를 선택하고 애플리케이션 서버 2로 지정한 컴퓨트 인스턴스를 선택합니다.
3. 비이동 인스턴스를 선택합니다. 이를 통해 OCI Full Stack DR은 DR 작업 중 대기 영역에서 복제된 가상 머신을 실행하려고 시도하지 않아야 함을 알립니다.
4. 추가를 눌러 DRPG에 컴퓨트 인스턴스를 추가합니다(표시되지 않음).

그림 4.1.3.2: 응용 프로그램 서버 2에 대한 매개변수를 지정합니다.

작업 4.1.4: 기본 클러스터화된 Oracle Database 추가

1. 멤버 추가를 눌러 데이터베이스를 멤버로 추가합니다.

   
   그림 4.1.4.1: [멤버 추가] 대화상자를 엽니다.

그림 4.1.4.2과 같이 영역 1에서 Oracle E-Business Suite용 RAC 데이터베이스를 선택합니다. 이는 단일 Instance 데이터베이스에서도 동일하게 작동합니다.

1. 데이터베이스를 리소스 유형으로 선택합니다. 데이터베이스 리소스 유형을 사용하면 Oracle E-Business Suite 엔지니어링에서 모두 지원되는 Oracle Base Database Service 또는 Oracle Exadata Database Service on Dedicated Infrastructure 중 하나를 적합한 선택으로 선택할 수 있습니다.
2. 이 그림은 Oracle Base Database Service를 보여 주지만 널리 사용되는 Oracle Exadata Database Service on Dedicated Infrastructure를 사용할 수도 있습니다.
3. 배포와 일치하는 해당 필드의 값을 선택합니다. 이러한 선택에 대한 답을 모르는 경우 데이터베이스 관리자에게 문의하십시오.
4. 데이터베이스에 대한 비밀번호를 포함하는 컴파트먼트 및 저장소 암호를 선택합니다. 작업 2.4의 일부로 영역 2에 유사한 저장소와 암호를 생성했어야 합니다. 이 매개변수는 다른 DBaaS API와의 호환성을 위해 대화상자에 있지만 비밀번호는 실제로 전혀 사용되지 않습니다.
5. 추가를 눌러 데이터베이스를 멤버로 추가합니다(표시되지 않음).

그림 4.1.4.2: 영역 1에서 RAC 데이터베이스에 대한 매개변수를 지정합니다.

DR 보호 그룹의 구성원 목록은 그림 4.1.4.3에 표시된 스크린샷과 같아야 합니다. 이 특정 DR 보호 그룹에 Oracle E-Business Suite 이상을 추가하거나 기존 DR 보호 그룹에 Oracle E-Business Suite 멤버 리소스를 추가하는 경우 목록이 달라질 수 있습니다.

그림 4.1.4.3: 영역 1의 Oracle E-Business Suite에 필요한 전체 멤버 목록

작업 4.2: 리전 2(애슈번)에서 DRPG에 멤버 리소스 추가

리스트에 표시된 리소스를 영역 2의 standby DRPG 멤버로 추가합니다.

1. 두 개의 비이동 Oracle E-Business Suite 응용 프로그램 서버(Oracle E-Business Suite가 설치되었지만 실행 중이 아님)
2. Oracle E-Business Suite용 RAC 데이터베이스(Oracle Data Guard 대기 피어)입니다.

Oracle E-Business Suite에서는 응용 프로그램이 설치된 두 영역 모두에 응용 프로그램 서버가 존재해야 합니다. 애플리케이션 서버는 Oracle E-Business Suite 애플리케이션이 설치된 대기 영역에서 항상 실행 중 상태여야 하지만 대기 영역에서는 실행 중이 아니어야 합니다.

즉, 운영체제 및 애플리케이션 업그레이드, 패치 및 기타 일상적인 유지 관리는 두 지역에서 독립적으로 수행해야 합니다.

OCI Full Stack DR은 VM이 다른 리전에 복제되지 않고 DR 작업 중 다른 리전으로 이동하지 않기 때문에 이 모델을 비이동 컴퓨트라고 합니다. OCI Full Stack DR에서 비이동 컴퓨트로 지정된 컴퓨트 인스턴스의 부트 장치는 대기 영역으로 복제하면 안됩니다. 따라서 비이동 컴퓨트용 부트 장치를 포함하는 복제된 블록 볼륨 그룹은 DRPG(DR Protection Groups)에 추가되지 않습니다.

주: 앞서 언급했듯이 Oracle E-Business Suite가 OCI Full Stack DR 보호 그룹 쌍과 연관된 유일한 애플리케이션 또는 서비스인 것은 드문 일입니다. 또한 대기 영역에서 DR 보호 그룹의 멤버로 다른 IaaS 및 PaaS 리소스를 사용할 수 있습니다.

작업 4.2.1: 대기 DR 보호 그룹으로 이동

그림 4.2.1과 같이 영역 2의 DR 보호 그룹으로 이동합니다.

1. OCI 지역 컨텍스트가 지역 2(애슈번)인지 확인합니다.
2. 영역 2에서 DR 보호 그룹을 선택합니다.

그림 4.2.1: 영역 2에서 DR 보호 그룹으로 이동합니다.

작업 4.2.2: Oracle E-Business Suite Application Server 1 추가

먼저 멤버 추가를 열어 첫번째 애플리케이션 서버를 추가합니다.

1. 멤버를 선택합니다.
2. 구성원 추가을 누릅니다.

그림 4.2.2.1: [멤버 추가] 대화상자를 엽니다.

그림 4.2.2.2과 같이 영역 2에서 응용 프로그램 서버 1을 선택합니다. 블록 볼륨 그룹은 비이동 인스턴스이므로 블록 볼륨 그룹을 추가하거나 네트워크 등록 정보를 지정할 필요가 없습니다.

1. 컴퓨트를 리소스 유형으로 선택합니다.
2. Oracle E-Business Suite 애플리케이션 서버가 포함된 컴파트먼트를 선택하고 애플리케이션 서버 1로 지정한 컴퓨트 인스턴스를 선택합니다.
3. 비이동 인스턴스를 선택합니다. 이를 통해 OCI Full Stack DR은 DR 작업 중 대기 영역에서 복제된 가상 머신을 실행하려고 시도하지 않아야 함을 알립니다.
4. 추가를 눌러 DRPG에 컴퓨트 인스턴스를 추가합니다(표시되지 않음).

그림 4.2.2.2: 응용 프로그램 서버 1에 대한 매개변수를 지정합니다.

작업 4.2.3: Oracle E-Business Suite Application Server 2 추가

1. 멤버 추가를 눌러 두번째 응용 프로그램 서버를 추가합니다.

   
   그림 4.2.3.1: [멤버 추가] 대화상자를 엽니다.

그림 4.2.3.2과 같이 영역 2에서 응용 프로그램 서버 2를 선택합니다. 블록 볼륨 그룹은 비이동 인스턴스이므로 블록 볼륨 그룹을 추가하거나 네트워크 등록 정보를 지정할 필요가 없습니다.

1. 컴퓨트를 리소스 유형으로 선택합니다.
2. Oracle E-Business Suite 애플리케이션 서버가 포함된 컴파트먼트를 선택하고 애플리케이션 서버 2로 지정한 컴퓨트 인스턴스를 선택합니다.
3. 비이동 인스턴스를 선택합니다. 이를 통해 OCI Full Stack DR은 DR 작업 중 대기 영역에서 복제된 가상 머신을 실행하려고 시도하지 않아야 함을 알립니다.
4. 추가를 눌러 DRPG에 컴퓨트 인스턴스를 추가합니다(표시되지 않음).

그림 4.2.3.2: 응용 프로그램 서버 2에 대한 매개변수를 지정합니다.

작업 4.2.4: Oracle Standby Clustered Database 추가

1. 멤버 추가를 눌러 데이터베이스를 멤버로 추가합니다.

   
   그림 4.2.4.1: [멤버 추가] 대화상자를 엽니다.

그림 4.2.4.2과 같이 영역 2에서 Oracle E-Business Suite용 RAC 데이터베이스를 선택합니다. 이는 단일 Instance 데이터베이스에서도 동일하게 작동합니다.

1. 데이터베이스를 리소스 유형으로 선택합니다. 데이터베이스 리소스 유형을 사용하면 Oracle E-Business Suite 엔지니어링에서 모두 지원되는 Oracle Base Database Service 또는 Oracle Exadata Database Service on Dedicated Infrastructure 중 하나를 적합한 선택으로 선택할 수 있습니다.
2. 아래 그림은 Oracle Base Database Service를 보여 주지만 널리 사용되는 Oracle Exadata Database Service on Dedicated Infrastructure를 사용할 수도 있습니다.
3. 배치와 일치하는 해당 필드의 값을 선택합니다. 이러한 선택에 대한 답을 모르는 경우 데이터베이스 관리자에게 문의하십시오.
4. 데이터베이스에 대한 비밀번호를 포함하는 컴파트먼트 및 저장소 암호를 선택합니다. 작업 2.4의 일부로 영역 2에 유사한 저장소와 암호를 생성했어야 합니다. 이 매개변수는 다른 DBaaS API와의 호환성을 위해 대화상자에 있지만 비밀번호는 실제로 전혀 사용되지 않습니다.
5. 추가를 눌러 데이터베이스를 멤버로 추가합니다(표시되지 않음).

그림 4.2.4.2: 영역 2에서 RAC 데이터베이스에 대한 매개변수를 지정합니다.

DR 보호 그룹의 구성원 목록은 그림 4.2.4.3에 표시된 스크린샷과 같아야 합니다. 이 특정 DR 보호 그룹에 Oracle E-Business Suite 이상을 추가하거나 기존 DR 보호 그룹에 Oracle E-Business Suite 멤버 리소스를 추가하는 경우 목록이 달라질 수 있습니다.

그림 4.2.4.3: 영역 2의 Oracle E-Business Suite에 필요한 전체 멤버 목록

작업 5: 영역 2에서 DR 계획 생성

이 작업은 영역 2(애슈번)에서 대기 DR 보호 그룹과 연관된 기본 전환, 페일오버 및 Startdrill 계획을 생성합니다.

각 계획의 목적은 작업 로드를 기본 영역 1에서 대기 영역 2로 전환하는 것입니다. 두 영역에서 DR 보호 그룹의 역할은 DR 작업의 일부로 자동으로 취소되므로 영역 1의 보호 그룹이 대기 상태가 되고 영역 2의 보호 그룹은 페일오버 또는 스위치오버 후 기본이 됩니다.

OCI Full Stack DR은 이전 작업에 추가된 멤버 리소스를 기반으로 내장된 단계로 두 계획을 미리 채웁니다. 계획은 복구 작업 중 Oracle E-Business Suite System과 관련된 모든 작업을 처리하기 위해 이후 단계에서 커스터마이즈됩니다.

DR 계획은 항상 대기 역할을 가진 보호 그룹에 생성됩니다. 영역 2는 현재 대기 보호 그룹이므로 애슈번에서 시작됩니다.

그림 5-1과 같이 영역 2에서 DRPG를 선택하여 기본 계획을 생성합니다.

1. OCI 지역 컨텍스트가 지역 2(애슈번)인지 확인합니다.
2. 영역 2에서 대기 DRPG를 선택합니다.
3. 플랜을 선택합니다.
4. 프로세스를 시작하려면 계획 생성을 누릅니다.

그림 5-0: 영역 2에서 기본 DR 계획 생성을 시작하는 방법

작업 5.1: 영역 2로 전환하기 위한 DR 계획 생성

DR 계획 만들기는 그림 5-2와 같이 간단합니다.

1. 전환 계획의 이름을 간단하지만 의미있는 이름으로 만드십시오. 이름은 가능한 한 짧지만 한 눈에 이해하기 쉬워 위기의 혼란과 인간의 실수를 줄일 수 있어야합니다.
2. 계획 유형을 선택합니다. 이 글쓰기에는 네 가지 계획 유형만 있습니다.

그림 5-1: DR 전환 계획을 만드는 데 필요한 매개변수

작업 5.2: 영역 2로 페일오버에 대한 DR 계획 만들기

그림 5-2와 같이 동일한 프로세스에 따라 기본 페일오버 계획을 만듭니다.

1. 복구 계획의 이름을 단순하지만 의미 있는 이름으로 만듭니다.
2. 계획 유형을 선택합니다. 이 글쓰기에는 네 가지 계획 유형만 있습니다.

그림 5-2: DR 페일오버 계획을 만드는 데 필요한 매개변수

작업 5.3: 영역 2에서 드릴 시작에 대한 DR 계획 생성

그림 5-3과 같이 동일한 프로세스에 따라 시작 드릴 평면도를 작성합니다.

1. 시작 드릴 계획의 이름을 단순하지만 의미 있는 이름으로 만듭니다.
2. 계획 유형을 선택합니다. 이 글쓰기에는 네 가지 계획 유형만 있습니다.

그림 5-3: DR Startdrill 계획을 생성하는 데 필요한 매개변수

이제 영역 2의 대기 DR 보호 그룹에는 다음 그림과 같이 3개의 DR 계획이 있어야 합니다. 리전 1에서 리전 2로 워크로드 전환을 처리합니다. 영역 1에서 유사한 계획을 생성하여 이후 작업에서 영역 2에서 영역 1로 작업 로드를 전환합니다.

그림 5-4: 추가로 진행하기 전에 영역 2에 존재해야 하는 세 가지 기본 DR 계획 표시

참고: OCI Full Stack DR은 Startdrill 계획이 성공적으로 실행된 후에만 Stopdrill 계획 생성을 지원합니다. 자습서의 경우 스톱 드릴 계획을 생성하는 것은 범위를 벗어났지만 두 DR 보호 그룹 모두에 스톱 드릴을 생성하는 것이 좋습니다.

작업 6: 리전 2(애슈번)에서 DR 계획 사용자 정의

OCI Full Stack DR에는 OCI Infrastructure as a Service(IaaS) 및 Platform as a Service(PaaS) 리소스에 대한 복구를 통합관리하기 위한 인텔리전스가 내장되어 있습니다. Oracle E-Business Suite는 현재 자체 내장된 재해 복구를 배포하거나 관리할 수 있는 OCI 네이티브 재해 복구 API를 제공하지 않으므로 OCI Full Stack DR에는 Oracle E-Business Suite에 대한 복구를 통합관리하기 위한 내장 인텔리전스가 없습니다.

그러나 OCI Full Stack DR은 사용자 정의 DR 계획 그룹 및 단계를 작업 5의 일부로 생성된 기본 DR 계획에 추가하여 Oracle E-Business Suite에 대한 복구를 통합관리할 수 있습니다. 사용자 정의 단계는 작업 2.3의 일부로 두 영역 또는 전용 DR 제어 노드의 Oracle E-Business Suite 응용 프로그램 서버에 다운로드 및 설치된 Oracle E-Business Suite 스크립트를 호출합니다. 다음은 상위 레벨의 사용자 정의 계획 그룹입니다. 추가해야 하는 계획 그룹은 DR 계획 유형에 따라 달라집니다.

1. Oracle E-Business Suite를 종료하고 영역 1의 node2에서 rsync 작업을 사용 안함으로 설정합니다.
2. Oracle E-Business SuiteS를 종료하고 영역 1의 node1에서 rsync 작업을 사용 안함으로 설정합니다.
3. 영역 2의 데이터베이스 FND 테이블에서 노드 이름을 지웁니다.
4. 영역 2의 node1에 있는 데이터베이스에서 앱 컨텍스트를 설정합니다.
5. 영역 2의 node2에 있는 데이터베이스에서 앱 컨텍스트를 설정합니다.
6. 영역 2에서 node1에 대해 autoconfig를 실행합니다.
7. 영역 2에서 node2에 대해 autoconfig를 실행합니다.
8. Oracle E-Business Suite를 시작하고 영역 2의 node1에서 rsync 작업을 활성화합니다.
9. Oracle E-Business Suite를 시작하고 영역 2의 node2에서 rsync 작업을 활성화합니다.

작업 6.1: 전환 계획 선택

먼저 작업 5에서 생성된 전환 계획으로 이동합니다.

그림 6.1: 영역 2에서 전환 계획을 선택합니다.

OCI Full Stack DR은 Prechecks-Built in 및 Databases-Switchover 계획 그룹을 생성합니다. 이 계획은 영역 1 및 영역 2의 DR 보호 그룹에 추가한 멤버를 기반으로 생성됩니다.

그림 6.1.1: 영역 2의 전환 계획에 대한 기본 계획 그룹

태스크 6.2: 영역 1에서 Oracle E-Business Suite를 종료하고 노드 2에서 재동기화 작업을 사용 안함으로 설정하는 계획 그룹 생성

이제 사용자 정의 DR 계획 그룹 추가를 시작합니다.

첫번째 사용자 정의 계획 그룹은 Oracle E-Business Suite를 종료하고 영역 1의 node2에서 재동기화 작업을 사용 안함으로 설정합니다. 이 계획 그룹에는 작업 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 shutdownapps.sh 및 fsdr-rsync-ebs.sh Bash 스크립트를 호출하는 두 단계가 포함됩니다.

작업 6.2.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6-2.1: Oracle E-Business Suite 종료에 계획 그룹 추가를 시작하고 node2에서 rsync 작업을 사용 안함으로 설정합니다.

작업 6.2.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

DR 계획 그룹에는 모두 병렬로 실행되는 여러 단계가 포함될 수 있습니다. node2에서 Oracle E-Business Suite를 정지하고 영역 1의 node2에서 rsync cron 작업을 사용 안함으로 설정하기 위해 bash 스크립트를 실행하는 두 단계를 추가하려고 합니다. 예제에서 node2의 이름은 ebshaapp02phx입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 데이터베이스 스위치오버 계획 그룹 앞에 추가합니다.
3. 내장된 데이터베이스 - 전환 계획 그룹을 선택합니다.
4. 우리는 두 단계를 추가 할 것입니다. 첫번째 단계는 노드 2에서 Oracle E-Business Suite를 정지하고 두번째 스크립트는 노드 2에서 rsync 작업을 비활성화하는 것입니다.
5. 단계 추가를 눌러 node2에서 Oracle E-Business Suite를 정지할 스크립트를 지정할 대화상자를 엽니다.

그림 6.2.2: Oracle E-Business Suite를 종료하고 rsync 작업을 중지할 계획 그룹

작업 6.2.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 두 단계를 추가합니다.

• 1단계는 node2에서 Oracle E-Business Suite 앱을 정지하는 것입니다.
• 단계 2: node2에서 rysnc 작업을 사용 안함으로 설정하는 것입니다.

이 설정에 대해 노드 2는 ebshaapp02phx입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 지역 1을 선택, 그래서 우리의 경우 그것은 피닉스입니다..

3. 로컬 스크립트 실행을 선택합니다.

4. Oracle E-Business Suite 앱 node2이 포함된 올바른 컴파트먼트를 선택하고 노드 2(ebshaapp02phx인 경우)를 선택합니다.

5. Oracle E-Business Suite 앱 node2에 shutdownapps.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node2에서 Oracle E-Business Suite 앱을 정지하지 못하면 DR 계획이 정지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 1800초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.2.3.1: 노드 2에서 Oracle E-Business Suite 정지를 위한 계획 단계를 생성하는 매개변수

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.2.3.2: 노드 2 단계에서 Stop Oracle E-Business Suite가 추가됩니다.

11. 단계 추가를 눌러 이 계획 그룹에 두번째 단계를 추가합니다.

12. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

13. Region 1을 선택합니다. 이 경우에는 Phoenix입니다.

14. 로컬 스크립트 실행을 선택합니다.

15. Oracle E-Business Suite 앱 node2이 포함된 올바른 컴파트먼트를 선택하고 노드 2(ebshaapp02phx인 경우)를 선택합니다.

16. Oracle E-Business Suite 앱 node2에 fsdr-rsync-ebs.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

17. 스크립트를 실행할 사용자로 oracle을 지정합니다.

18. 스크립트가 node2에서 rsync 작업을 사용 안함으로 설정하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

19. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 300초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

20. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

    
    그림 6.2.3.1: 노드 2에서 rysnc 작업을 사용 안함으로 설정하는 계획 단계를 생성하는 매개변수입니다.

21. 단계 2가 추가되면 아래와 같이 표시됩니다.

    
    그림 6.2.3.2: 노드 2에서 rysnc 작업 사용 안함이 추가됩니다.

작업 6.2.4: 계획 그룹 및 단계 추가 완료

둘 다 Oracle E-Business Suite 앱을 중지하고 node2에서 rsync 작업을 사용 안함으로 설정하면 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.2.4.1: 계획 그룹 및 단계 추가를 완료하여 Oracle E-Business Suite를 정지하고 node1에서 rsync 작업을 사용 안함으로 설정합니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.2.4.1: 추가된 node1 계획 그룹에서 Oracle E-Business Suite를 정지하고 rsync 작업을 사용 안함으로 설정합니다.

태스크 6.3: 영역 1에서 Oracle E-Business Suite를 종료하고 노드 1에서 재동기화 작업을 사용 안함으로 설정하는 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 Oracle E-Business Suite를 종료하고 영역 1의 node1에서 재동기화 작업을 사용 안함으로 설정합니다. 이 계획 그룹에는 작업 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 shutdownapps.sh 및 fsdr-rsync-ebs.sh Bash 스크립트를 호출하는 두 단계가 포함됩니다.

작업 6.3.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6-3.1: Oracle E-Business Suite 종료에 계획 그룹 추가를 시작하고 node1에서 rsync 작업을 사용 안함으로 설정합니다.

작업 6.3.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

DR 계획 그룹에는 모두 병렬로 실행되는 여러 단계가 포함될 수 있습니다. node1에서 Oracle E-Business Suite를 정지하고 영역 1의 node1에서 rsync cron 작업을 사용 안함으로 설정하기 위해 bash 스크립트를 실행하는 두 단계를 추가하려고 합니다. 예제에서 node1의 이름은 ebshaapp01phx입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. In this case, we are going to insert our user-defined plan group add after the Shutdown EBS on node2 at PHX plan group.
3. 사용자 정의 PHX의 node2에서 EBS 종료 계획 그룹을 선택합니다.
4. 우리는 두 단계를 추가 할 것입니다. 첫번째 단계는 노드 1에서 Oracle E-Business Suite를 정지하고 두번째 스크립트는 노드 1에서 rsync 작업을 비활성화하는 것입니다.
5. 단계 추가를 눌러 node2에서 Oracle E-Business Suite를 정지할 스크립트를 지정할 대화상자를 엽니다.

그림 6.3.2: Oracle E-Business Suite를 종료하고 rsync 작업을 중지할 계획 그룹

작업 6.3.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 두 단계를 추가합니다.

• 1단계는 node1에서 Oracle E-Business Suite 앱을 정지하는 것입니다.
• Step 2는 node1에서 rysnc 작업을 사용 안함으로 설정하는 것입니다.

이 설정에 대해 노드 1은 ebshaapp01phx입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. Region 1을 선택합니다. 이 경우에는 Phoenix입니다.

4. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp01phx인 경우)을 선택합니다.

5. Oracle E-Business Suite 앱 node2에 shutdownapps.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node1에서 Oracle E-Business Suite 앱을 정지하지 못하면 DR 계획이 정지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 1800초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.3.3.1: 노드 1에서 Oracle E-Business Suite 정지를 위한 계획 단계를 생성하는 매개변수

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.3.3.2: 노드 1 단계에서 Stop Oracle E-Business Suite가 추가됩니다.

11. 단계 추가를 눌러 이 계획 그룹에 두번째 단계를 추가합니다.

12. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

13. Region 1을 선택합니다. 이 경우에는 Phoenix입니다.

14. 로컬 스크립트 실행을 선택합니다.

15. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp02phx인 경우)을 선택합니다.

16. Oracle E-Business Suite 앱 node2에 fsdr-rsync-ebs.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

17. 스크립트를 실행할 사용자로 oracle을 지정합니다.

18. 스크립트가 node1에서 rsync 작업을 사용 안함으로 설정하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

19. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 300초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

20. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

    
    그림 6.3.3.1: 노드 1에서 rysnc 작업을 사용 안함으로 설정하는 계획 단계를 생성하는 매개변수입니다.

21. 단계 2가 추가되면 아래와 같이 표시됩니다.

    
    그림 6.3.3.2: 노드 1에서 rysnc 작업 사용 안함이 추가됩니다.

태스크 6.3.4: 계획 그룹 및 단계 추가 완료

둘 다 Oracle E-Business Suite 앱을 중지하고 node2에서 rsync 작업을 사용 안함으로 설정하면 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.3.4.1: 계획 그룹 및 단계 추가를 완료하여 Oracle E-Business Suite를 정지하고 node1에서 rsync 작업을 사용 안함으로 설정합니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.3.4.1: 추가된 node1 계획 그룹에서 Oracle E-Business Suite를 정지하고 rsync 작업을 사용 안함으로 설정합니다.

작업 6.4: 영역 2의 데이터베이스 fnd 테이블에서 노드 이름을 지울 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 영역 2의 데이터베이스 fnd 테이블에서 노드 이름을 지웁니다. 이 계획 그룹에는 태스크 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 fndnodeclean.sh Bash 스크립트를 호출하는 한 단계가 포함됩니다.

작업 6.4.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6.4.1: Oracle E-Business Suite 종료에 계획 그룹 추가를 시작하고 node1에서 rsync 작업을 사용 안함으로 설정합니다.

작업 6.4.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

bash 스크립트를 실행하여 영역 1의 node1에 있는 데이터베이스 fnd 테이블에서 노드 이름을 지우는 스크립트를 하나 추가하려고 합니다. 예제에서 node1의 이름은 ebshaapp01iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 데이터베이스 - 전환 계획 그룹 다음 뒤에 추가합니다.
3. 내장된 데이터베이스 - 전환 계획 그룹을 선택합니다.
4. 한 단계를 추가하여 데이터베이스 fnd 테이블에서 노드 이름을 지웁니다.
5. 단계 추가를 눌러 데이터베이스 fnd 테이블에서 노드 이름을 지울 스크립트를 지정할 대화상자를 엽니다.

그림 6.4.2: 데이터베이스 fnd 테이블에서 노드 이름을 지우도록 그룹을 계획합니다.

작업 6.4.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 단일 항목을 추가합니다.

• 단계는 node1에서 fndnodeclean를 실행하는 것입니다.

이 설정에 대해 노드 1은 ebshaapp01iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp01iad인 경우)을 선택합니다.

5. Oracle E-Business Suite 앱 node1에 fndnodeclean.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node1에서 Oracle E-Business Suite 앱을 정지하지 못하면 DR 계획이 정지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 900초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.4.3.1: 데이터베이스 FND 테이블에서 노드 이름을 지우는 계획 단계를 생성하는 매개변수

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.4.3.2: 데이터베이스 fnd 테이블에서 노드 이름을 지웁니다.

태스크 6.4.4: 계획 그룹 및 단계 추가 완료

데이터베이스 FND 테이블에서 노드 이름을 지우는 단계가 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.4.4.1: 계획 그룹 및 단계 추가를 완료하여 데이터베이스 FND 테이블에서 노드 이름을 지웁니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.4.4.2: node1 계획 그룹의 데이터베이스 fnd 테이블에서 노드 이름을 지우려면 다음을 추가했습니다.

작업 6.5: 영역 2의 node1에서 데이터베이스에 앱 컨텍스트를 설정하기 위한 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 영역 2의 node1에서 데이터베이스에 앱 컨텍스트를 설정합니다. 이 계획 그룹에는 태스크 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 dbtxkconfig.sh Bash 스크립트를 호출하는 한 단계가 포함됩니다.

작업 6.5.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6.5.1: node1에서 데이터베이스의 앱 컨텍스트 설정에 계획 그룹 추가를 시작합니다.

작업 6.5.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

bash 스크립트를 실행하여 영역 2의 node1에 있는 데이터베이스에서 앱 컨텍스트를 설정하는 한 단계를 추가하려고 합니다. 예제에서 node1의 이름은 ebshaapp01iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 IAD 계획 그룹의 데이터베이스 FND 테이블에서 노드 이름 지우기를 다음 뒤에 추가하는 사용자 정의 계획 그룹을 삽입하려고 합니다.
3. 내장된 IAD의 데이터베이스 FND 테이블에서 노드 이름 지우기 계획 그룹을 선택합니다.
4. node1의 데이터베이스에서 앱 컨텍스트를 설정하는 한 단계를 추가합니다.
5. 단계 추가를 눌러 node1의 데이터베이스에서 앱 컨텍스트를 설정할 스크립트를 지정할 대화상자를 엽니다.

그림 6.5.2: node1의 데이터베이스에 앱 컨텍스트를 설정하도록 계획 그룹입니다.

작업 6.5.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 단일 항목을 추가합니다.

• 단계는 node1에서 dbtxkconfig를 실행하는 것입니다(물리적 호스트 이름 변경).

이 설정에 대해 노드 1은 ebshaapp01iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp01iad인 경우)을 선택합니다.

5. Oracle E-Business Suite 앱 node1에 dbtxkconfig.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다. 적합한 매개변수로 모든 세부정보를 제공하는 것이 매우 중요합니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node1 데이터베이스에서 앱 컨텍스트 설정을 실패하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 900초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.5.3.1: 데이터베이스 node1에서 앱 컨텍스트를 설정하는 계획 단계를 생성하는 매개변수입니다.

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.5.3.2: 데이터베이스 node1에서 앱 컨텍스트를 설정하려면 다음과 같이 하십시오.

태스크 6.5.4: 계획 그룹 및 단계 추가 완료

데이터베이스 node1에서 앱 컨텍스트를 설정하는 단계가 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.5.4.1: 데이터베이스 node1에서 계획 그룹 및 단계 추가를 완료하여 앱 컨텍스트를 설정합니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.5.4.2: 데이터베이스 node1 계획 그룹에서 앱 컨텍스트를 설정하려면 다음을 추가했습니다.

작업 6.6: 영역 2의 node2에 있는 데이터베이스에서 앱 컨텍스트를 설정하기 위한 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 영역 2의 node2에서 데이터베이스에 앱 컨텍스트를 설정합니다. 이 계획 그룹에는 태스크 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 dbtxkconfig.sh Bash 스크립트를 호출하는 한 단계가 포함됩니다.

작업 6.6.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6.6.1: node2에서 데이터베이스의 앱 컨텍스트 설정에 계획 그룹 추가를 시작합니다.

작업 6.6.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

bash 스크립트를 실행하여 영역 2의 node2에 있는 데이터베이스에서 앱 컨텍스트를 설정하는 한 단계를 추가하려고 합니다. 예제에서 node2의 이름은 ebshaapp02iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 다음 뒤에 추가하여 IAD의 node1에 있는 데이터베이스의 앱 컨텍스트 설정 계획 그룹에 삽입하려고 합니다.
3. 내장된 IAD의 node1에 있는 데이터베이스에서 앱 컨텍스트 설정 계획 그룹을 선택합니다.
4. node2의 데이터베이스에서 앱 컨텍스트를 설정하는 한 단계를 추가합니다.
5. 단계 추가를 눌러 node1의 데이터베이스에서 앱 컨텍스트를 설정할 스크립트를 지정할 대화상자를 엽니다.

그림 6.6.2: node2의 데이터베이스에 앱 컨텍스트를 설정하도록 계획 그룹입니다.

작업 6.6.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 단일 항목을 추가합니다.

• 단계는 node2에서 dbtxkconfig를 실행하는 것입니다(물리적 호스트 이름 변경).

이 설정에 대해 노드 2는 ebshaapp02iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp02iad인 경우)을 선택합니다.

5. Oracle E-Business Suite 앱 node1에 dbtxkconfig.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다. 적합한 매개변수로 모든 세부정보를 제공하는 것이 매우 중요합니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node2 데이터베이스에서 앱 컨텍스트 설정을 실패하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 900초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.6.3.1: 데이터베이스 node2에서 앱 컨텍스트를 설정하는 계획 단계를 생성하는 매개변수입니다.

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.6.3.2: 데이터베이스 node2에서 앱 컨텍스트를 설정하려면 다음과 같이 하십시오.

작업 6.6.4: 계획 그룹 및 단계 추가 완료

데이터베이스 node1에서 앱 컨텍스트를 설정하는 단계가 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.6.4.1: 데이터베이스 node2에서 계획 그룹 및 단계 추가를 완료하여 앱 컨텍스트를 설정합니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.6.4.2: 데이터베이스 node2 계획 그룹에서 앱 컨텍스트를 설정하려면 다음을 추가했습니다.

작업 6.7: 영역 2의 앱 node1에서 autoconfig를 실행할 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 영역 2의 앱 node1에서 autoconfig를 실행합니다. 이 계획 그룹에는 태스크 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 autoconfigapps.sh Bash 스크립트를 호출하는 한 단계가 포함됩니다.

작업 6.7.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6.7.1: node1 앱에서 자동 구성을 실행할 계획 그룹 추가를 시작합니다.

작업 6.7.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

영역 2의 앱 node1에서 autoconfig를 실행하는 bash 스크립트를 실행하는 한 단계를 추가하려고 합니다. 예제에서 node1의 이름은 ebshaapp01iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 다음 뒤에 추가하여 IAD의 node2에 있는 데이터베이스의 앱 컨텍스트 설정 계획 그룹에 삽입하려고 합니다.
3. 내장된 IAD의 node2에 있는 데이터베이스에서 앱 컨텍스트 설정 계획 그룹을 선택합니다.
4. node2의 데이터베이스에서 앱 컨텍스트를 설정하는 한 단계를 추가합니다.
5. 단계 추가를 눌러 node1 앱에서 autoconfig를 실행할 스크립트를 지정할 대화상자를 엽니다.

그림 6.7.2: node1 앱에서 자동 구성을 실행할 계획 그룹입니다.

작업 6.7.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 단일 항목을 추가합니다.

• 단계는 node1에서 autoconfig를 실행하는 것입니다.

이 설정에 대해 노드 1은 ebshaapp01iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp01iad인 경우)을 선택합니다.

5. Oracle E-Business Suite 앱 node1에 autoconfigapps.sh 스크립트를 설치한 절대 경로를 올바른 매개변수와 함께 붙여넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다. 적합한 매개변수로 모든 세부정보를 제공하는 것이 매우 중요합니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node1 앱에서 autoconfig 실행을 실패하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 900초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.7.3.1: 앱 node1에서 자동 구성을 실행하는 계획 단계를 생성하는 매개변수입니다.

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.7.3.2: node1 앱에서 자동 구성을 실행하려면 다음과 같이 하십시오.

작업 6.7.4: 계획 그룹 및 단계 추가 완료

node1 앱에서 autoconfig를 실행하는 단계가 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.7.4.1: 앱에서 자동 구성을 실행할 계획 그룹 및 단계 추가를 완료합니다. node1

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.7.4.2: 추가된 앱 node1 계획 그룹에서 자동 구성을 실행하려면 다음과 같이 하십시오.

작업 6.8: 영역 2의 앱 node2에서 autoconfig를 실행할 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 영역 2의 앱 node2에서 autoconfig를 실행합니다. 이 계획 그룹에는 태스크 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 autoconfigapps.sh Bash 스크립트를 호출하는 한 단계가 포함됩니다.

작업 6.8.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6.8.1: node2 앱에서 자동 구성을 실행할 계획 그룹 추가를 시작합니다.

작업 6.8.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

bash 스크립트를 실행하여 영역 2의 앱 node2에서 autoconfig를 실행하는 한 단계를 추가하려고 합니다. 예제에서 node2의 이름은 ebshaapp02iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 다음 뒤에 추가하여 IAD의 앱 node1에서 자동 구성 실행 계획 그룹에 삽입하려고 합니다.
3. 내장된 IAD의 앱 node1에서 자동 구성 실행 계획 그룹을 선택합니다.
4. node2의 데이터베이스에서 앱 컨텍스트를 설정하는 한 단계를 추가합니다.
5. 단계 추가를 눌러 node2 앱에서 autoconfig를 실행할 스크립트를 지정할 대화상자를 엽니다.

그림 6.8.2: node2 앱에서 자동 구성을 실행할 계획 그룹입니다.

작업 6.8.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 단일 항목을 추가합니다.

• 단계는 node2에서 autoconfig를 실행하는 것입니다.

이 설정에 대해 노드 1은 ebshaapp02iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node2이 포함된 올바른 컴파트먼트를 선택하고 노드 2(ebshaapp02iad인 경우)를 선택합니다.

5. Oracle E-Business Suite 앱 node1에 autoconfigapps.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다. 적합한 매개변수로 모든 세부정보를 제공하는 것이 매우 중요합니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node2 앱에서 자동 구성을 실행하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 900초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.8.3.1: 앱 node2에서 자동 구성을 실행하는 계획 단계를 생성하는 매개변수입니다.

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.8.3.2: node2 앱에서 자동 구성을 실행하려면 다음과 같이 하십시오.

작업 6.8.4: 계획 그룹 및 단계 추가 완료

node2 앱에서 autoconfig를 실행하는 단계가 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.8.4.1: 앱에서 자동 구성을 실행할 계획 그룹 및 단계 추가를 완료합니다. node2

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.8.4.2: 추가된 앱 node2 계획 그룹에서 자동 구성을 실행하려면 다음과 같이 하십시오.

태스크 6.9: 영역 2의 노드 1에서 Oracle E-Business Suite를 시작하고 재동기화 작업을 사용으로 설정할 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 Oracle E-Business Suite를 시작하고 영역 2의 node1에서 rsync 작업을 사용으로 설정합니다. 이 계획 그룹에는 작업 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 startapps.sh 및 fsdr-rsync-ebs.sh Bash 스크립트를 호출하는 두 단계가 포함됩니다.

작업 6.9.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6-9.1: Oracle E-Business Suite 시작에 계획 그룹 추가를 시작하고 node1에서 rsync 작업을 사용으로 설정합니다.

작업 6.9.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

DR 계획 그룹에는 모두 병렬로 실행되는 여러 단계가 포함될 수 있습니다. node1에서 Oracle E-Business Suite를 시작하고 영역 2의 node1에서 rsync cron 작업을 사용으로 설정하기 위해 bash 스크립트를 실행하는 두 단계를 추가하려고 합니다. 예제에서 node1의 이름은 ebshaapp01iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 다음 뒤에 추가하여 IAD의 앱 node2에서 자동 구성 실행 계획 그룹에 삽입하려고 합니다.
3. 사용자 정의 IAD의 앱 node2에서 자동 구성 실행 계획 그룹을 선택합니다.
4. 우리는 두 단계를 추가 할 것입니다. 첫 번째 단계는 노드 1에서 Oracle E-Business Suite를 시작하고 두 번째 스크립트는 노드 1에서 rsync 작업을 활성화하는 것입니다.
5. 단계 추가를 눌러 node2에서 Oracle E-Business Suite를 시작할 스크립트를 지정할 대화상자를 엽니다.

그림 6.9.2: ebs를 시작하고 node1에서 rsync 작업을 사용으로 설정할 계획 그룹입니다.

작업 6.9.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 두 단계를 추가합니다.

• 1단계는 node1에서 Oracle E-Business Suite 앱을 시작하는 것입니다.
• Step 2는 node1에서 rysnc 작업을 사용으로 설정하는 것입니다.

이 설정의 경우 노드 1은 ebshaapp01iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp01iad인 경우)을 선택합니다.

5. Oracle E-Business Suite 앱 node1에 startapps.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node1에서 Oracle E-Business Suite 앱을 시작하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 1800초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.9.3.1: 노드 1에서 Oracle E-Business Suite를 시작하기 위한 계획 단계를 생성하는 매개변수

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.9.3.2: 노드 1 단계에서 Oracle E-Business Suite 시작이 추가됩니다.

11. 단계 추가를 눌러 이 계획 그룹에 두번째 단계를 추가합니다.

12. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

13. 지역 2를 선택합니다. 이 경우 애슈번입니다.

14. 로컬 스크립트 실행을 선택합니다.

15. Oracle E-Business Suite 앱 node1가 포함된 올바른 컴파트먼트를 선택하고 노드 1(ebshaapp0iad인 경우)을 선택합니다.

16. Oracle E-Business Suite 앱 node1에 fsdr-rsync-ebs.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

17. 스크립트를 실행할 사용자로 oracle을 지정합니다.

18. 스크립트가 node1에서 rsync 작업을 사용으로 설정하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

19. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 300초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

20. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

    
    그림 6.9.3.1: 노드 1에서 rysnc 작업을 사용으로 설정하는 계획 단계를 생성하는 매개변수입니다.

21. 단계 2가 추가되면 아래와 같이 표시됩니다.

    
    그림 6.9.3.2: 노드 1에서 rysnc 사용 작업이 추가되었습니다.

작업 6.9.4: 계획 그룹 및 단계 추가 완료

둘 다 Oracle E-Business Suite 앱을 시작하고 node1에서 rsync 작업을 사용으로 설정하는 것이 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.9.4.1: 계획 그룹 및 단계 추가를 완료하여 Oracle E-Business Suite를 시작하고 node1에서 rsync 작업을 사용으로 설정합니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.9.4.1: 추가된 node1 계획 그룹에서 Oracle E-Business Suite를 시작하고 rsync 작업을 사용으로 설정합니다.

태스크 6.10: 영역 2의 노드 2에서 Oracle E-Business Suite를 시작하고 재동기화 작업을 사용으로 설정할 계획 그룹 생성

이제 다음 사용자 정의 계획 그룹을 추가합니다.

이 사용자 정의 계획 그룹은 Oracle E-Business Suite를 시작하고 영역 2의 node2에서 rsync 작업을 사용으로 설정합니다. 이 계획 그룹에는 작업 2.3의 Oracle E-Business Suite 앱 서버 노드로 다운로드된 startapps.sh 및 fsdr-rsync-ebs.sh Bash 스크립트를 호출하는 두 단계가 포함됩니다.

작업 6.10.1: 계획 그룹 추가 선택

계획 그룹 추가 프로세스를 시작합니다.

1. 시작하려면 그룹 추가를 누릅니다.

   
   그림 6-10.1: Oracle E-Business Suite 시작에 계획 그룹 추가를 시작하고 node2에서 rsync 작업을 사용으로 설정합니다.

작업 6.10.2: 계획 그룹 이름 제공, 순서 지정 및 단계 추가

DR 계획 그룹에는 모두 병렬로 실행되는 여러 단계가 포함될 수 있습니다. node1에서 Oracle E-Business Suite를 시작하고 영역 2의 node1에서 rsync cron 작업을 사용으로 설정하기 위해 bash 스크립트를 실행하는 두 단계를 추가하려고 합니다. 예제에서 node1의 이름은 ebshaapp02iad입니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 사용자 정의 계획 그룹을 다음 뒤에 추가하여 IAD의 node1에서 EBS 시작 계획 그룹에 삽입하려고 합니다.
3. 사용자 정의 IAD의 node1에서 EBS 시작 계획 그룹을 선택합니다.
4. 우리는 두 단계를 추가 할 것입니다. 첫번째 단계는 노드 2에서 Oracle E-Business Suite를 시작하고 두번째 스크립트는 노드 2에서 rsync 작업을 활성화하는 것입니다.
5. 단계 추가를 눌러 node2에서 Oracle E-Business Suite를 시작할 스크립트를 지정할 대화상자를 엽니다.

그림 6.10.2: Oracle E-Business Suite를 시작하고 node2에서 rsync 작업을 사용으로 설정하는 계획 그룹입니다.

작업 6.10.3: 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업 및 복구 중 작동 방식에 대한 매개변수를 지정할 수 있습니다. 이 계획 그룹에 두 단계를 추가합니다.

• 1단계는 node2에서 Oracle E-Business Suite 앱을 시작하는 것입니다.
• Step 2는 node2에서 rysnc 작업을 사용으로 설정하는 것입니다.

이 설정에 대해 노드 2는 ebshaapp02iad입니다.

이 대화 상자의 모든 필드에 대해 설명하겠지만, 동일한 프로세스를 반복해서 수행하기 때문에 이후 단계의 모든 나머지 스크린샷에 이 세부 정보를 남겨 둡니다.

1. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

2. 사용자 정의 유형을 로컬 스크립트 실행으로 선택합니다.

3. 지역 2를 선택합니다. 이 경우 애슈번입니다.

4. Oracle E-Business Suite 앱 node1이 포함된 올바른 컴파트먼트를 선택하고 노드 2(ebshaapp02iad인 경우)를 선택합니다.

5. Oracle E-Business Suite 앱 node1에 startapps.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

6. 스크립트를 실행할 사용자로 oracle을 지정합니다.

7. 스크립트가 node2에서 Oracle E-Business Suite 앱을 시작하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

8. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 1800초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

9. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

   
   그림 6.10.3.1: 노드 2에서 Oracle E-Business Suite를 시작하기 위한 계획 단계를 생성하는 매개변수

10. 단계 1이 추가되면 아래와 같이 표시됩니다.

    
    그림 6.10.3.2: 노드 2 단계에서 Oracle E-Business Suite 시작이 추가됩니다.

11. 단계 추가를 눌러 이 계획 그룹에 두번째 단계를 추가합니다.

12. 이 단계가 수행하는 작업을 설명하는 설명적 이름입니다.

13. 지역 2를 선택합니다. 이 경우 애슈번입니다.

14. 로컬 스크립트 실행을 선택합니다.

15. Oracle E-Business Suite 앱 node1이 포함된 올바른 컴파트먼트를 선택하고 노드 2(ebshaapp0iad인 경우)를 선택합니다.

16. Oracle E-Business Suite 앱 node1에 fsdr-rsync-ebs.sh 스크립트를 설치한 절대 경로를 올바른 매개변수로 붙여 넣습니다. 정확한 구문은 작업 2.3에 제공된 GitHub 링크에서 readme 세부 정보를 참조할 수 있습니다.

17. 스크립트를 실행할 사용자로 oracle을 지정합니다.

18. 스크립트가 node2에서 rsync 작업을 사용으로 설정하지 못하면 DR 계획이 중지되어야 합니다. 이렇게하면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후에도 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.

19. OCI Full Stack DR이 Failure를 선언하기 전의 기본값은 60분(3600초)입니다. 이 값은 300초 또는 보다 사실적인 시간 초과 값으로 느껴지는 값으로 변경할 수 있습니다.

20. 단계 추가를 눌러 계획 그룹에 이 단계를 추가합니다.

    
    그림 6.10.3.1: 노드 2에서 rysnc 작업을 사용으로 설정하는 계획 단계를 생성하는 매개변수입니다.

21. 단계 2가 추가되면 아래와 같이 표시됩니다.

    
    그림 6.10.3.2: 노드 2에서 rysnc 사용 작업이 추가되었습니다.

작업 6.10.4: 계획 그룹 및 단계 추가 완료

둘 다 Oracle E-Business Suite 앱을 시작하고 node2에서 rsync 작업을 사용으로 설정하는 것이 DR 계획 그룹에 추가됩니다.

1. DR 계획 그룹 및 단계를 DR 계획에 추가하려면 추가를 누릅니다.

   
   그림 6.10.4.1: 계획 그룹 및 단계 추가를 완료하여 Oracle E-Business Suite를 시작하고 node2에서 rsync 작업을 사용으로 설정합니다.

2. 추가된 계획 그룹을 전환 계획에서 사용할 수 있는지 확인합니다.

   
   그림 6.10.4.1: 추가된 node2 계획 그룹에서 Oracle E-Business Suite를 시작하고 rsync 작업을 사용으로 설정합니다.

주: 이를 통해 전환 계획에 대해 필요한 모든 사용자 정의 계획 그룹을 완료했습니다. 올바른 순서로 계획 그룹을 가지고 있는지 확인하십시오. 이것은 매우 중요합니다.

전환 계획이 사용자 정의되면 다음과 같이 표시되어야 합니다.

그림 6.10.5.1: 영역 2의 전환 계획에 대한 모든 계획 그룹

주: 올바른 순서로 주문하지 않은 경우 계획 그룹의 순서를 재지정할 수 있습니다.

작업 6.11: Failover 계획 선택

먼저 이전 작업에서 만든 페일오버 계획으로 이동합니다.

그림 6.11: 영역 2에서 페일오버 계획을 선택합니다.

OCI Full Stack DR은 Prechecks-Built in 및 Databases-Failover 계획 그룹을 생성합니다. 이 계획은 영역 1 및 영역 2의 DR 보호 그룹에 추가한 멤버를 기반으로 생성됩니다.

그림 6.11.1: 영역 2의 페일오버 계획에 대한 기본 계획 그룹

전환 계획을 사용자 정의한 방식과 마찬가지로, 페일오버 계획에 필요한 사용자 정의 계획 그룹을 추가합니다.

내장된 계획 그룹 데이터베이스-페일오버 뒤에 다음과 같이 언급된 사용자 정의 계획 그룹을 추가해야 합니다.

1. 영역 2의 데이터베이스 fnd 테이블에서 노드 이름을 지웁니다.
2. 영역 2의 node1에 있는 데이터베이스에서 앱 컨텍스트를 설정합니다.
3. 영역 2의 node2에 있는 데이터베이스에서 앱 컨텍스트를 설정합니다.
4. 영역 2에서 node1에 대해 autoconfig를 실행합니다.
5. 영역 2에서 node2에 대해 autoconfig를 실행합니다.
6. Oracle E-Business Suite를 시작하고 영역 2의 node1에서 rsync 작업을 활성화합니다.
7. Oracle E-Business Suite를 시작하고 영역 2의 node2에서 rsync 작업을 활성화합니다.

주: 사용자 정의 계획 그룹을 다시 추가하는 단계는 진행하지 않습니다. 자세한 지침은 작업 6.4 - 6.9를 참조하십시오.

복구 계획이 사용자 정의되면 다음과 같이 표시되어야 합니다.

그림 6.11.1: 영역 2의 페일오버 계획에 대한 모든 계획 그룹

참고:

• 올바른 순서로 주문하지 않은 경우 계획 그룹의 순서를 재지정할 수 있습니다.

• 드릴 시작 계획을 사용자정의할 수도 있습니다.

  시작 드릴 계획의 경우 데이터베이스에 대해 생성된 내장 계획 그룹이 없습니다.

  물리적 대기 데이터베이스를 스냅샷 대기 데이터베이스로 변환하려면 사용자 정의 계획 그룹을 만들어야 합니다. 표준 Oracle Data Guard Broker 명령을 사용하여 이러한 작업을 수행하고 래퍼 스크립트에 넣을 수 있습니다.

  또한 페일오버 계획에 대해 수행하는 작업과 유사한 응용 프로그램 관련 사용자 정의 계획 그룹을 추가할 수 있습니다.

• OCI Full Stack DR은 Startdrill 계획이 실행된 후 Stopdrill 계획을 생성할 수 있습니다. 자세한 내용은 DR 드릴 계획을 참조하십시오. 드릴 중지 계획이 시작 드릴 계획에서 수행된 작업을 취소하는 중입니다.

• 드릴 중지 계획을 사용자정의할 수도 있습니다.

  Stopdrill 계획의 경우 데이터베이스에 대해 생성된 내장 계획 그룹이 없습니다.

  스냅샷 대기를 물리적 데이터베이스로 변환하려면 사용자 정의 계획 그룹을 만들어야 합니다. 표준 Oracle Data Guard Broker 명령을 사용하여 이러한 작업을 수행하고 래퍼 스크립트에 넣을 수 있습니다.

  또한 애플리케이션 관련 사용자 정의 계획 그룹을 추가하여 모든 Oracle E-Business Suite 관련 애플리케이션을 정지할 수 있습니다.

이 자습서의 일부로 후속 작업에서 **스위치오버 계획을 실행합니다.**

작업 7: 리전 2(애슈번)에서 Switchover Plan 실행

스위치오버 및 페일오버 DR 계획이 모두 대기 영역 2(애슈번)에 생성되었습니다. 리전 2의 DR 계획을 통해 OCI Full Stack DR은 리전 1에서 리전 2로 워크로드를 전환할 수 있습니다. 다음 작업은 리전 1(피닉스)에 대한 보호 그룹에 스위치오버, 페일오버 및 Startdrill 계획을 생성하여 OCI Full Stack DR이 리전 2에서 다시 리전 1로 워크로드를 전환할 수 있도록 하는 것입니다.

하지만 DR 계획은 대기 역할을 가진 보호 그룹에서만 만들고 수정할 수 있습니다. 영역 1의 DR 보호 그룹은 현재 기본입니다. 즉, 영역 1에서 DR 계획을 생성할 수 없습니다.

따라서 영역 1은 대기이고 영역 2는 기본이 되도록 보호 그룹의 롤을 되돌려야 합니다. 방금 생성한 switchover 계획을 실행하여 작업 로드를 리전 1(피닉스)에서 리전 2(애슈번)로 전환합니다.

작업 7.1: 계획 실행 시작

DR 계획을 실행하여 Oracle Integration Cloud 워크로드를 리전 1에서 리전 2로 전환하는 프로세스를 시작합니다.

1. 영역 컨텍스트가 여전히 대기 영역 2(애슈번)로 설정되어 있는지 확인합니다.
2. 콘솔 상단의 이동 경로를 사용하여 DR 보호 그룹 세부정보가 현재 계획 컨텍스트인지 확인합니다.
3. 영역 2에서 올바른 DR 보호 그룹이 선택되었는지 확인합니다. Standby 역할이어야 합니다.
4. 계속하기 전에 페일오버 및 스위치오버 계획이 모두 존재하는지 확인합니다. 존재하지 않을 경우 이전 단계로 돌아가서 두 DR 계획을 만들고 사용자 정의합니다.
5. DR 계획 실행을 누릅니다.

그림 7-1: 대기 영역으로 스위치오버를 실행하는 방법을 보여줍니다.

작업 7.2: 전환 계획 선택 및 실행

이 작업은 영역 2에서 switchover 계획을 실행합니다.

1. 전환 계획을 선택합니다.
2. 사전 검사 사용을 선택합니다.
3. 시작하려면 DR 계획 실행을 누릅니다.

그림 7-2: 전환 계획을 선택하고 실행합니다.

작업 7.3: DR 계획 실행 모니터

Oracle E-Business Suite 워크로드가 리전 1에서 리전 2로 완전히 전환될 때까지 스위치오버 계획을 모니터링합니다. 전환 계획이 성공적으로 완료되면 OCI Full Stack DR은 리전 간 기본 및 대기 DR 보호 그룹의 역할 변경을 정리합니다.

리전 2(피닉스)는 기본 리전이 되고 리전 1(애슈번)은 OCI Full Stack DR이 전환을 완료한 후 대기 리전이 됩니다.

1. switchover plan 실행이 성공했는지 확인합니다.

   
   그림 7-2: 전환 계획이 영역 2에서 성공적으로 완료되었습니다.

2. DR 보호 그룹의 역할 변경 사항을 확인합니다. 이제 지역 2(피닉스)에 대기 역할이 지정되고 지역 1(애슈번)에 기본 역할이 지정됩니다.

   
   그림 7-2: 전환 계획 후 DR 보호 그룹 롤 변경

작업 8: 지역 1에서 DR 생성 및 DR 계획 사용자 정의(피닉스)

이제 대기 피어인 영역 1(피닉스)에서 DR 보호 그룹에 DR 계획을 생성합니다.

각 계획의 목적은 지역 2가 기본 피어일 때마다 지역 2에서 지역 1로 작업 로드를 전환하는 것입니다. 두 영역에서 DR 보호 그룹의 역할은 자동으로 DR 작업의 일부로 되돌려지므로 영역 2의 보호 그룹이 대기 상태가 되고 영역 1의 보호 그룹이 페일오버 또는 스위치오버 후 기본이 됩니다.

OCI Full Stack DR은 이전 단계에서 추가된 멤버 리소스를 기반으로 내장된 단계로 두 계획을 미리 채웁니다. 계획은 복구 작업 중 Oracle Integration Cloud와 관련된 모든 작업을 처리하기 위해 이후 단계에서 사용자정의됩니다.

DR 계획은 항상 대기 롤을 가진 보호 그룹에 생성됩니다. 영역 1은 현재 작업 7에서 전환 계획을 실행한 후 대기 보호 그룹입니다.

작업 5와 동일한 프로세스에 따라 영역 1에서 DR 계획을 생성합니다. 계획이 생성되면 계획을 확인합니다.

그림 8-1: 영역 1의 DR 계획

작업 6과 동일한 프로세스에 따라 영역 1에서 DR 계획을 사용자 정의합니다. 사용자 정의 계획 그룹을 추가하여 확인하십시오. 스크립트를 실행하기 위해 프로덕션 및 DR 영역에 적합한 Oracle E-Business Suite 애플리케이션 VM을 선택하는 것이 매우 중요합니다.

1. Oracle E-Business Suite를 종료하고 영역 2의 node2에서 rsync 작업을 사용 안함으로 설정합니다.
2. Oracle E-Business Suite를 종료하고 영역 2의 node1에서 rsync 작업을 사용 안함으로 설정합니다.
3. 영역 1의 데이터베이스 FND 테이블에서 노드 이름을 지웁니다.
4. 영역 1의 node1에 있는 데이터베이스에서 앱 컨텍스트를 설정합니다.
5. 영역 1의 node2에 있는 데이터베이스에서 앱 컨텍스트를 설정합니다.
6. 영역 1에서 node1에 대해 autoconfig를 실행합니다.
7. 영역 1에서 node2에 대해 autoconfig를 실행합니다.
8. Oracle E-Business Suite를 시작하고 영역 1의 node1에서 rsync 작업을 사용으로 설정합니다.
9. Oracle E-Business Suite를 시작하고 영역 1의 node2에서 rsync 작업을 사용으로 설정합니다.

전환 계획이 사용자 정의되면 다음과 같이 표시되어야 합니다.

그림 8.2: 영역 1의 전환 계획에 대한 모든 계획 그룹

복구 계획이 사용자 정의되면 다음과 같이 표시되어야 합니다.

그림 8.3: 영역 1의 페일오버 계획에 대한 모든 계획 그룹

참고:

• 올바른 순서로 주문하지 않은 경우 계획 그룹의 순서를 재지정할 수 있습니다.

• 드릴 시작 계획을 사용자정의할 수도 있습니다.

  시작 드릴 계획의 경우 데이터베이스에 대해 생성된 내장 계획 그룹이 없습니다.

  물리적 대기 데이터베이스를 스냅샷 대기 데이터베이스로 변환하려면 사용자 정의 계획 그룹을 만들어야 합니다. 표준 Oracle Data Guard Broker 명령을 사용하여 이러한 작업을 수행하고 래퍼 스크립트에 넣을 수 있습니다.

  또한 페일오버 계획에 대해 수행하는 작업과 유사한 응용 프로그램 관련 사용자 정의 계획 그룹을 추가할 수 있습니다.

• OCI Full Stack DR은 Startdrill 계획이 실행된 후 Stopdrill 계획을 생성할 수 있습니다. 자세한 내용은 DR 드릴 계획을 참조하십시오. 드릴 중지 계획이 시작 드릴 계획에서 수행된 작업을 취소하는 중입니다.

• 드릴 중지 계획을 사용자정의할 수도 있습니다.

  Stopdrill 계획의 경우 데이터베이스에 대해 생성된 내장 계획 그룹이 없습니다.

  스냅샷 대기를 물리적 데이터베이스로 변환하려면 사용자 정의 계획 그룹을 만들어야 합니다. 표준 Oracle Data Guard Broker 명령을 사용하여 이러한 작업을 수행하고 래퍼 스크립트에 넣을 수 있습니다.

  또한 애플리케이션 관련 사용자 정의 계획 그룹을 추가하여 모든 Oracle E-Business Suite 관련 애플리케이션을 정지할 수 있습니다.

다음 단계

이 시점에서 Oracle E-Business Suite용 OCI Full Stack DR을 완전히 구현해야 합니다. 그러나 프로덕션에 OCI Full Stack DR을 사용하기 전에 전체 기능을 검증해야 합니다. 모든 페일오버 및 스위치오버 계획을 실행하여 모든 작업이 예상대로 작동하는지 검증하고 복구 팀이 전체 프로세스를 완전히 이해해야 합니다.

전환 계획 테스트

전환 계획은 모든 아티팩트를 정리하고 OCI 로드 밸런서, OCI 블록 스토리지, OCI 파일 시스템, Oracle Base Database Service 및 Oracle Autonomous Database와 같은 기본 제공 복구 단계에 대한 모든 역할이 사람의 개입 없이 대기 영역에서 복구될 준비가 되었는지 확인하기 위해 설계되었습니다.

테스트 페일오버 계획

페일오버는 다릅니다. 기본적으로 페일오버는 아티팩트를 정리하거나 실패한 영역의 서비스와 데이터베이스가 작업 로드를 다시 영역 1로 전환할 준비가 되었는지 확인할 수 없습니다. 복구 팀은 Oracle Data Guard가 올바른 상태인지, 스토리지 및 컴퓨트 인스턴스에 대한 아티팩트가 종료되었는지 확인하기 위한 작업을 이해하고 수행해야 합니다. 자세한 내용은 Resetting DR Configuration After a Failover을 참조하십시오.

최종 수락에 대한 모든 DR 계획 검증

복구 팀은 OCI Full Stack DR 보호 그룹의 준비 상태와 프로덕션 워크로드에 대한 계획을 입증하기 위해 최종 검증을 수행해야 합니다. 프로세스 시점의 지역 2(애슈번)가 기본 지역이어야 합니다. 다음 단계를 완료하여 모든 계획의 최종 검증을 시작합니다.

• 영역 2(기본)에서 영역 1(대기)로 다시 전환을 테스트합니다.
• 영역 1(기본)에서 영역 2(대기)로의 복구를 테스트합니다.
• 영역 2에서의 페일오버에 대해 영역 1(기본)을 준비합니다.
• 영역 2(기본)에서 영역 1(대기)로의 복구를 테스트합니다.
• 영역 2(기본) 준비 - 페일오버 또는 영역 2로 스위치오버
• DR 보호 그룹 및 응용 프로그램 스택은 정상 작동 상태이며 이 시점에서 페일오버 또는 스위치오버를 수행할 준비가 되어 있어야 합니다.
• 요구 사항에 따라 두 영역 중 하나에서 DR 드릴 계획을 실행할 수도 있습니다.

이 솔루션에 대한 지원 받기

OCI Full Stack DR 엔지니어링은 이 솔루션에 대한 1단계 지원을 제공합니다.

그러나 이 자습서에 제공된 솔루션 및 모든 사용자정의 자동화는 Oracle E-Business Suite 조직 또는 OCI Full Stack DR 엔지니어링 팀과 독립적으로 Oracle Cloud EMEA 전문가 팀에 의해 개발 및 구현되었습니다.

Oracle E-Business Suite와 OCI Full Stack DR 간의 관계

OCI Full Stack DR은 Oracle E-Business Suite 설치 또는 배포 프로세스의 일부가 아니며 Oracle E-Business Suite에서 작성 및 유지 관리하는 설명서에 언급되지 않습니다. OCI 리전 간의 재해 복구를 위해 Oracle E-Business Suite를 설치, 구성 및 배포하는 방법은 byOracle E-Business Suite 엔지니어링을 고안하고 작성했으며 이 사용지침서 또는 OCI Full Stack DR과 완전히 독립적입니다.

Oracle E-Business Suite 조직은 OCI Full Stack DR에 익숙하지 않으며 OCI Full Stack DR 외부에서 수동으로 실행된 재해 복구를 위해 Oracle E-Business Suite가 작성한 설명서에 설명된 대로 Oracle E-Business Suite 프로세스 관련 문제만 해결하는 데 도움이 될 수 있습니다.

Oracle E-Business Suite에서 문서화된 수동 Oracle E-Business Suite 프로세스 관련 문제 해결은 Oracle E-Business Suite 지원의 책임이며 OCI Full Stack DR과 독립적으로 수행됩니다. OCI Full Stack DR은 고객 또는 Oracle E-Business Suite 지원이 문서화된 Oracle E-Business Suite 재해 복구 프로세스를 수동으로 실행하는 것을 방해하지 않습니다. 따라서 Oracle E-Business Suite 지원은 OCI Full Stack DR을 사용하지 않고도 수동 재해 복구 프로세스 관련 문제를 해결할 수 있습니다.

그러나 Oracle E-Business Suite에서 문서화된 수동 복구 프로세스를 살펴보면 OCI Full Stack DR 보호 그룹을 사용할 수 없는 상태로 유지할 수 있습니다. 이 상태는 Oracle E-Business Suite에서 OCI Full Stack DR을 사용하여 작업을 재개하기 전에 재설정해야 합니다. OCI Full Stack DR 지원은 Oracle E-Business Suite 지원이 수동 문제 해결 및 해결을 완료한 후 고객이 DR 보호 그룹을 재설정할 수 있도록 지원합니다.

OCI Full Stack DR을 통한 지원 시작

OCI Full Stack DR 지원은 이 자습서에 설명된 단계 및 작업에서 발생하는 모든 문제에 대한 지원을 위한 첫번째 연락 창구입니다. OCI Full Stack DR 지원은 문제를 격리하고 문제 해결에 가장 적합한 지원 조직을 결정합니다.

1. OCI Full Stack DR 지원은 다음을 담당합니다.
   1. 고객이 DR 작업 중에 생성되는 오류 메시지의 의미와 원인을 파악할 수 있도록 지원합니다.
   2. 고객이 DR 작업 중 전체 스택 DR이 리소스를 관리하지 못하도록 방지하는 IAM 정책 관련 문제를 해결할 수 있도록 지원합니다.
   3. DR 보호 그룹을 만들거나 관리하는 데 문제가 있습니다.
   4. Oracle E-Business Suite 또는 EMEA 클라우드 솔루션 팀에서 제공하는 사용자정의 자동화를 적절히 호출하기 위한 DR 계획 생성, 실행 또는 실패의 문제입니다.
   5. 고객은 이 사용지침서의 일부가 아닌 고객이 작성한 커스텀 스크립트와 관련된 문제를 해결하고 해결할 책임이 있습니다.
2. OCI Full Stack DR 지원은 Oracle E-Business Suite 자체와 직접 관련된 모든 문제에 대해 Oracle E-Business Suite 지원이 포함된 SR을 개설합니다. 고객은 Oracle E-Business Suite 지원과 직접 협력하여 Oracle E-Business Suite 관련 문제를 해결할 수 있습니다. Oracle E-Business Suite는 다음 사항을 담당합니다.
   1. Oracle E-Business Suite에서 작성 및 유지 관리하는 MOS(My Oracle Support) 설명서의 모든 문제.
   2. Oracle E-Business Suite에서 고객에게 제공하는 스크립트의 모든 문제입니다.
   3. Oracle E-Business Suite와 관련된 모든 데이터베이스 문제.
   4. Oracle E-Business Suite와 관련된 모든 애플리케이션 문제.
   5. OCI Full Stack DR 외부에서 Oracle E-Business Suite를 수동으로 복구하기 위한 문서화된 Oracle E-Business Suite 프로세스 관련 문제.
3. OCI Full Stack DR 지원은 이 사용지침서에 설명된 스크립트 또는 프로세스와 직접 관련된 모든 문제에 대해 적절한 내부 Oracle Cloud Solutions 팀과 함께 SR을 개설합니다. 고객은 Oracle Cloud Solutions 팀과 직접 협력하여 이 사용지침서의 문제를 해결하게 됩니다. Oracle Cloud Solutions 팀은 다음을 담당합니다.
   1. 클라우드 솔루션 팀에서 제공하는 사용자정의 스크립트와 관련된 모든 문제입니다.
   2. 이 자습서에 설명된 대로 전체 프로세스에 문제가 있습니다.

지원 요청을 여는 방법

OCI 콘솔을 사용하여 OCI Full Stack DR 지원으로 지원 요청을 엽니다. 이 프로세스를 시작하기 전에 이 자습서의 일부로 만든 DR 보호 그룹이 브라우저 컨텍스트에 표시되는지 확인합니다.

1. 브라우저 컨텍스트가 적절한 DR 보호 그룹으로 설정되었는지 확인합니다.
2. OCI 콘솔에서 Life Preserver를 선택합니다.
3. 지원 요청 생성을 선택합니다.

그림 5: OCI 콘솔 도움말 툴을 사용하여 서비스 요청 열기

그림 6: 지원 요청은 도움말 요청 버튼을 사용하여 열어야 합니다.

관련 링크

• OCI 전체 스택 재해 복구 제품 페이지

• OCI Full Stack Disaster Recovery 설명서

• Oracle 샘플 Oracle E-Business Suite 스크립트

• 전체 스택 재해 복구 - 사용자 정의 그룹 스크립트

• #full-stack-dr 공용 슬랙 채널 가입

승인

• Authors - Chandra Dharanikota(Oracle Apps to OCI Specialist, Oracle Technology Cloud Engineering, EMEA), Suraj Ramesh - (Full Stack DR, 기술 검토자)

추가 학습 자원

docs.oracle.com/learn에서 다른 랩을 탐색하거나 Oracle Learning YouTube 채널에서 더 많은 무료 학습 콘텐츠에 액세스하세요. 또한 education.oracle.com/learning-explorer를 방문하여 Oracle Learning Explorer가 되십시오.

제품 설명서는 Oracle Help Center를 참조하십시오.

---

제목 및 저작권 정보

Automate Recovery for Multi-Node Oracle E-Business Suite Using OCI Full Stack Disaster Recovery

G35486-02

Copyright ©2025, Oracle and/or its affiliates.