주:

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

OCI Full Stack Disaster Recovery를 사용하여 Oracle Integration의 복구 자동화

1부: 소개

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

Oracle Integration은 클라우드 및 온프레미스 애플리케이션을 연결하고, 비즈니스 프로세스를 자동화하고, 비즈니스 측정지표 분석을 통해 비즈니스에 대한 통찰력을 얻고, 웹 및 모바일 애플리케이션을 개발할 수 있는 안전한 통합 플랫폼입니다. Oracle Integration은 SLA(서비스 수준 계약)에 따라 관리되는 OCI 지역에서 사용할 수 있습니다. 이 사용지침서에서는 특히 Oracle Integration의 통합 기능을 위해 Oracle Integration에 대해 지역 간 고객 관리 재해 복구 솔루션을 구축하는 절차에 대해 자세히 설명합니다.

Oracle Integration은 Oracle Integration 자체가 OCI 사용자에게 컴퓨트, 스토리지 또는 데이터베이스를 노출하지 않으므로 OCI Full Stack DR이 기본적으로 관리할 수 있는 것이 아닌 관리형 OCI Platform as a Service(PaaS) 제품입니다. 그러나 OCI Full Stack DR은 Oracle Integration과 같은 특정 서비스에 대한 엔지니어링 팀이 OCI 지역 간의 재해 복구를 위해 서비스를 프로비저닝, 구성 및 복구하는 방법을 문서화한 경우 PaaS 제공 서비스에 대한 복구를 자동화할 수 있습니다. Oracle Integration 엔지니어링 팀은 Oracle Integration을 수동으로 프로비저닝, 구성 및 복구하는 방법을 설명하는 Oracle Integration 2세대용 재해 복구 솔루션 구성을 문서화했습니다.

OCI 전체 스택 재해 복구(DR)는 Oracle Integration을 프로비전 또는 구성하는 데 사용되지 않습니다. OCI Full Stack DR을 어떤 방식으로든 사용하기 전에 Configuring a Disaster Recovery Solution for Oracle Integration Generation 2에 나와 있는 단계별 지침에 따라 여러 지역에서 Oracle Integration을 프로비전하고 DR용으로 구성해야 합니다.

OCI Full Stack DR을 사용하기 전에 Oracle Integration 엔지니어링에서 규정한 수동 페일오버 단계: Configuring a Disaster Recovery Solution for Oracle Integration Generation 2도 스위치오버 및 스위치백에 대해 성공적으로 테스트해야 합니다.

Oracle Integration은 일반적으로 더 큰 시스템의 일부입니다.

이 자습서에서는 Oracle Integration이 DR 보호 그룹에 추가되는 유일한 응용 프로그램이라고 가정합니다. 이는 정상이 아닙니다.

이 자습서는 문서 전체에서 Oracle Integration만 표시되고 설명되어 작업을 단순하게 유지하는 것이 일반적입니다. 일반적으로 Oracle Integration은 단일 OCI 전체 스택 DR 보호 그룹 및 DR 계획 세트에 다양한 서비스와 애플리케이션을 포함하는 훨씬 더 크고 복잡한 비즈니스 시스템의 작은 부분 중 하나입니다. PeopleSoft, WebLogic Server, Oracle Analytics Cloud 등과 같은 다른 애플리케이션 및 서비스에 대해 유사한 OHC(Oracle Help Center) 튜토리얼을 따를 가능성이 높습니다.

주: 이 자습서의 단계는 Oracle Integration 2세대를 사용하여 테스트되었습니다. 이 자습서에서는 Oracle Integration Generation 2의 애플리케이션 통합 기능을 위해 DR을 구현하는 방법을 보여줍니다. 움직이는 부품과 조각을 너무 많이 도입하여 독자를 압도하고 싶지 않기 때문입니다.

증분 구현에 대한 주의

DR 계획을 생성한 후 DR 보호 그룹에 멤버를 더 추가하면 두 영역의 보호 그룹에 있는 모든 기존 DR 계획이 삭제됩니다.

OCI Full Stack DR은 지정된 비즈니스 시스템의 전체 애플리케이션 스택이 OCI 리전 전체에 이미 배포되었으며 수동 DR이 이미 작동한다는 가정 하에 설계되었습니다. 비즈니스 시스템에 Oracle Integration 이상이 포함된 경우 DR 계획을 생성하기 전에 다른 모든 애플리케이션 또는 OCI 서비스의 모든 멤버를 DR 보호 그룹에 추가합니다.

복구 작동 방법

Oracle Integration용 복구 솔루션을 사용하려면 복구 작업 중 페일오버 또는 스위치오버와 같은 일련의 사용자정의 bash 스크립트를 실행하기 위해 OCI 전체 스택 DR이 필요합니다. 이 자습서에서 참조된 스크립트는 Oracle Integration 전문가 팀에서 제공하며 이 Oracle Integration DR 솔루션에 맞게 특별히 조정된 GitHub 저장소에서 사용할 수 있습니다. bash 스크립트는 복구 작업 중 OCI Full Stack DR이 관리할 애플리케이션 스택의 일부인 컴퓨트 인스턴스로 다운로드됩니다.

다음 스크립트는 일반적인 지침을 위해 제공됩니다. 자체 스크립트를 사용하거나 회사 정책 및 보안 요구 사항에 따라 스크립트를 사용자 정의할 수 있습니다. 스크립트를 사용하려면 OCI CLI를 설치하고 인증서를 구성해야 합니다.

또한 기본 인스턴스가 최신 일정이 잡힌 매개변수로 업데이트되도록 하려면 integrations.json 파일이 모든 일정이 잡힌 통합에 대해 최신 일정이 잡힌 매개변수 값으로 업데이트되어야 하는 integration_parameters.json 파일과 함께 버전 세부정보와 함께 모든 통합 이름으로 업데이트되는지 확인하십시오. 이를 위해 선호하는 CI/CD 프로세스를 사용할 수 있습니다.

이 자습서에서는 스크립트를 다운로드하는 방법과 이후 단계에서 스크립트를 사용하는 방법에 대해 설명합니다. 이 자습서에서는 자습서에 Oracle Integration 이외의 항목이 포함되어 있지 않으므로 아래 옵션 2를 사용하여 bash 스크립트를 호스팅합니다.

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

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

이 자습서에서는 애플리케이션 스택의 다른 목적을 실제로 충족하더라도 이 특정 컴퓨트 인스턴스를 제어 노드 또는 DR 노드라고 합니다.

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

Oracle Integration이 복구 작업 중 OCI 전체 스택 DR이 관리할 유일한 애플리케이션 서비스인 경우 스크립트를 호스트하기 위해서만 컴퓨트 인스턴스를 생성해야 합니다.

일반적으로 OCI Full Stack DR은 복구 작업을 자동화하는 데 특수 관리 서버가 필요하지 않습니다. 그러나 Oracle Integration은 OCI Full Stack DR이 기본적으로 관리할 수 있는 것이 아니므로 이 경우 특수 관리 서버 역할을 하는 컴퓨트 인스턴스를 생성합니다. 특수 관리 서버는 이 문서 전체에서 제어 노드 또는 DR 노드로 표시됩니다. 제어 노드의 전체 목적은 단순히 복구 작업 중 사용자정의 스크립트가 상주하고 OCI 전체 스택 DR에 의해 호출될 수 있는 서버 역할을 하는 것입니다. 이 자습서에서는 DR 계획의 일부로 사용자정의 DR 계획 그룹 및 단계를 생성하여 제어 노드에 설치된 스크립트를 호출하는 방법에 대해 설명합니다.

Oracle Integration 배치 구조

그림에 표시된 것처럼 Oracle Integration 2세대 DR 구조에는 기본 및 보조 인스턴스로 구분된 두 개의 Oracle Integration 인스턴스가 동시에 작동합니다. 그러나 트래픽은 한 번에 하나의 인스턴스로만 전달됩니다. 처음에는 트래픽이 기본 인스턴스로 흐릅니다. 기본 인스턴스를 사용할 수 없게 되면 DNS 레코드가 조정되어 트래픽이 보조 인스턴스로 재지정됩니다.

그림 1: Oracle Integration DR 참조 아키텍처

인스턴스가 프로비저닝되면 기본 인스턴스의 메타데이터를 대기 인스턴스로 내보냅니다. REST API를 사용하거나 Oracle Integration UI를 활용하여 메타데이터를 익스포트 및 임포트하여 이 작업을 수행할 수 있습니다. 이 초기 메타데이터의 일회성 이전이 완료된 후에는 CICD를 사용하여 인스턴스 간에 메타데이터를 동기화된 상태로 유지해야 합니다. Jenkins 또는 유사한 툴을 사용하여 인스턴스에 대한 CICD를 구현하고 메타데이터를 동기화할 수 있습니다. OCI 컴퓨팅 인스턴스를 Jenkins CI 서버 및 CD 허브로 사용할 수도 있습니다.

OCI Full Stack DR을 도입하기 전에 먼저 OCI 리전 전반의 재해 복구(DR)를 위해 Oracle Integration을 프로비저닝하고 구성해야 합니다. OCI Full Stack DR을 사용하여 전환/페일오버 프로세스를 자동화하기 전에 Oracle Integration 엔지니어링에 설명된 대로 Oracle Integration 전환을 위한 수동 단계를 테스트하고 올바르게 작동하는 것이 매우 중요합니다.

전체 프로세스에 대한 이해

전체 스택 재해 복구 엔지니어링 팀은 전체 프로세스 흐름을 이해하기 위해이 자습서에 대한 일련의 동반자 비디오를 만들었습니다. 이 비디오는 다음 링크를 사용하여 액세스할 수 있는 YouTube의 OCI Full Stack DR Oracle Integration 재생 목록의 일부입니다.

• 비디오 1: 재해 복구를 위한 Oracle Integration 배포.
• 비디오 2: OCI Full Stack DR을 사용하여 Oracle Integration에 대한 재해 복구 작업 자동화.
• 비디오 3: Oracle Integration의 복구를 자동화하는 데 사용되는 스크립트.

2부: 단계별 지침

이 부분에서는 Oracle Integration을 OCI Full Stack DR에 추가하는 데 필요한 단계별 지침을 시작합니다.

목표

이 자습서에서는 OCI Full Stack DR을 사용하여 Oracle Integration에 대한 복구를 자동화하는 방법을 설명하는 다음 단계를 다룹니다.

1. 작업 1: OCI 리전 전체에 DR용 Oracle Integration 배포
   1. Oracle Integration DR 제어 노드 준비
   2. DR 제어 노드에 사용자정의 스크립트 다운로드
   3. 두 OCI 리전에서 수동으로 Oracle Integration for DR 설치 및 배포
   4. 원하는 영역 1에서 영역 2까지의 모든 Recovery 단계 수동 테스트
   5. 원하는 영역 2에서 영역 1까지의 모든 Recovery 단계 수동 테스트
2. 작업 2: OCI 전체 스택 DR 준비
   1. OCI 전체 스택 DR에 대한 IAM 정책 생성
   2. 기타 OCI 서비스에 대한 IAM 정책 생성
   3. 로그에 대한 오브젝트 스토리지 버킷 생성
3. 작업 3: DRPG(DR 보호 그룹) 생성
4. 작업 4: 영역 1에 멤버 추가 DRPG
5. 작업 5: 영역 2에서 DR 계획 생성(피닉스)
   1. 전환 계획 생성
   2. 복구 계획 생성
6. 작업 6: 영역 2의 전환 계획 사용자 정의(피닉스)
7. 작업 7: 영역 2에서 페일오버 계획 사용자 정의(피닉스)
8. 작업 8: 영역 2에서 switchover 계획 실행(피닉스)
9. 작업 9: 영역 1에서 기본 DR 계획 생성(애슈번)
   1. 전환 계획 생성
   2. 복구 계획 생성
10. 작업 10: 영역 1의 전환 계획 사용자 정의(애슈번)
11. 작업 11: 영역 1에서 페일오버 계획 사용자 정의(애슈번)

자습서 전체에서 정의 및 가정

영역

• 지역 1은 애슈번
  • 애슈번이 기본 지역으로 시작됩니다.
  • 이 롤은 이후 단계에서 switchover를 수행하라는 지시를 받은 후에 결국 standby로 변경됩니다.
• 지역 2는 피닉스
  • Phoenix는 대기 영역으로 시작됩니다.
  • 이 롤은 이후 단계에서 switchover를 수행하라는 지시를 받은 후에 결국 primary로 변경됩니다.

구획

Oracle Integration 및 OCI 전체 스택 DR을 IT 거버넌스 표준 내에서 작동하는 모든 구획 체계로 자유롭게 구성할 수 있습니다. 애플리케이션을 자체 개별 구획으로 구성한 다음 모든 DR 보호 그룹을 완전히 다른 비즈니스 시스템을 한 눈에 볼 수 있는 단일 구획으로 구성하기로 결정했습니다.

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

Oracle Integration DR 제어 노드

DR 제어 노드는 Oracle Integration 복구를 위해 특정 작업을 수행하는 사용자정의 bash 스크립트를 호스트하도록 지정하는 컴퓨트 인스턴스입니다. 이 스크립트는 복구 작업 중 OCI 전체 스택 DR에 의해 호출됩니다. 이 사용지침서에서는 6, 7, 10 및 11단계에서 스크립트를 OCI Full Stack DR에 추가하는 방법에 대해 설명합니다.

• Oracle Integration의 경우 독립형 애플리케이션: 사용자정의 스크립트의 호스트로 작동하도록 생성하는 특수 컴퓨트 인스턴스입니다.
• Oracle Integration의 경우 애플리케이션 스택의 일부: DRPG(DR 보호 그룹)의 멤버인 기존 컴퓨트 인스턴스가 됩니다. 예를 들어, Oracle E-Business Suite 또는 PeopleSoft에는 Oracle Integration에 대한 복구를 관리하는 동일한 DRPG의 멤버인 애플리케이션 서버가 있습니다. 이 튜토리얼에서 이 중 하나가 DR 제어 노드의 역할을 수행할 수 있습니다.

필요 조건

OCI Full Stack DR 작업을 시작하기 전에 두 지역에 걸쳐 재해 복구를 위해 Oracle Integration을 배포해야 합니다. 이 내용은 아래의 작업 1에서 다룹니다.

작업 1: 재해 복구를 위해 Oracle Integration 배치

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

작업 1.1: 사용자 정의 자동화를 실행하도록 DR 제어 노드 준비

OIC에 대한 DR 제어 노드로 작동할 컴퓨트 인스턴스를 지정합니다. 기존 컴퓨트 인스턴스일 수도 있고, 이 용도로만 생성된 컴퓨트 인스턴스일 수도 있습니다. 자세한 내용은 아래 옵션을 참조하십시오. DR 제어 노드로 작동하는 컴퓨트 인스턴스가 OCI 클라우드 에이전트 인스턴스에서 명령 실행을 사용하여 명령을 실행하도록 구성되었는지 확인합니다.

옵션 1: 독립형 애플리케이션으로 사용되는 Oracle Integration

이 사용지침서에서는 Oracle Integration이 독립형 서비스라고 가정하므로 영역 1에서 Oracle Linux를 사용하여 컴퓨트 인스턴스를 생성합니다. Oracle Linux는 사용자정의 bash 스크립트를 호스트하는 데만 사용되므로 가장 낮은 비용의 구성을 사용합니다. 이 역할을 수행하는 데 특화된 컴퓨트 인스턴스가 필요한 것은 드문 경우입니다. 옵션 2는 대부분의 조직에서 가장 일반적인 시나리오입니다.

특수 컴퓨트 인스턴스는 이후 단계에서 영역 1의 DR 보호 그룹 멤버로 추가됩니다.

옵션 2: 애플리케이션 스택의 일부로 Oracle Integration 사용

리전 1에서 OCI Full Stack DR에 의해 관리되고 있는 Oracle 또는 비Oracle 애플리케이션의 일부인 기존의 이동식 컴퓨트를 모두 사용할 수 있습니다. 이 자습서가 DR 제어 노드를 참조할 때마다 DR 제어 노드의 역할을 수행합니다.

이동식 컴퓨트 인스턴스를 사용하는 것이 가장 좋지만, DR 솔루션의 일부로 이동식 컴퓨트가 없는 경우 영역 1과 영역 2에 이동식 컴퓨트 인스턴스를 지정할 수도 있습니다. 이동할 수 없는 컴퓨트가 이 역할에 사용되는 경우 두 영역에서 스크립트 또는 게스트 OS에 대한 변경사항을 유지 관리해야 합니다.

옵션 3: Oracle Integration(여러 PaaS 제공 서비스가 포함된 애플리케이션 스택의 일부)

비즈니스 시스템에는 OHS(Oracle HTTP Server), Oracle Integration 및 ODI(Oracle Data Integrator)도 있습니다. 이 경우 다양한 모든 PaaS 서비스에 대한 DR 복구 스크립트를 호스트하기 위해 옵션 1과 마찬가지로 특수 컴퓨트 인스턴스를 만드는 것이 좋습니다.

작업 1.2: 볼륨 그룹이 영역 2로 복제되는지 확인합니다.

DR 제어 노드의 부트 볼륨이 블록 볼륨 그룹의 멤버이고 블록 볼륨 그룹이 영역 2로 복제되었는지 확인합니다.

이 OCI Full Stack DR 프로젝트에 대한 다른 이동식 컴퓨트에 속한 기타 모든 부트 및 블록이 영역 2에 복제된 블록 볼륨 그룹에도 속하는지 확인하십시오. 자세한 내용은 OCI Block Storage 설명서를 참고하세요.

작업 1.3: DR 제어 노드로 bash 스크립트 다운로드

이 Oracle Integration DR 솔루션용으로 특별히 작성된 github에서 사용자정의 bash 스크립트를 다운로드합니다. 아래에 표시된 스크립트는 Oracle Integration의 DR 제어 노드 역할을 하는 컴퓨트 인스턴스의 하위 디렉토리에 복사해야 합니다.

위의 링크는 GitHub 저장소로 분석되어야 합니다.

1. bash 스크립트가 GitHub에 있는 저장소 경로를 보여줍니다.
2. bash 스크립트를 포함하는 저장소를 표시합니다.

그림 2-4: Oracle Integration에 대한 bash 스크립트를 포함하는 github 저장소 스크린샷

작업 1.4: DR용 Oracle Integration 배치

Oracle Integration Engineering 팀이 제공하는 단계별 지침을 사용하여 OCI 지역 전반에 DR용 Oracle Integration 배포.

작업 1.5: Oracle Integration의 수동 테스트 복구

수동 복구 단계를 보장하는 것이 좋습니다. OCI Full Stack DR을 사용하기 전에 Disaster Recovery Configuration for Oracle Integration에 설명된 Oracle Integration을 복구하는 수동 단계가 성공해야 합니다.

작업 1.6: 다음 단계

다음 요구사항이 완료되면 이 문서로 돌아가서 OCI Full Stack DR 작업을 시작하십시오.

1. Oracle Integration for DR을 두 개의 원하는 OCI 리전에 수동으로 배포합니다.
2. 리전 1(애슈번)에서 리전 2(피닉스)까지의 모든 복구 단계를 수동으로 테스트합니다.
3. 리전 2(피닉스)에서 리전 1(애슈번)까지의 모든 복구 단계를 수동으로 테스트합니다.

작업 2: OCI 전체 스택 DR 준비

OCI 전체 스택 DR은 이 단계의 어떤 부분에도 포함되지 않습니다. 다음 단계는 OCI Full Stack DR의 자동 복구를 위해 테넌시, 구획, OCI 서비스 및 Oracle Integration을 준비합니다.

작업 2.1: OCI 전체 스택 DR에 대한 IAM 정책 생성

다음 문서에 설명된 대로 전체 스택 재해 복구에 필요한 OCI IAM 정책을 구성합니다.

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

작업 2.2: OCI 전체 스택 DR에서 관리되는 다른 서비스에 대한 OCI IAM 정책 생성

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

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

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

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

복구 작업 중 OCI Full Stack DR에서 생성된 로그를 저장할 OCI Object Storage 버킷을 기본 및 대기 영역에 생성합니다. Object Storage.

작업 2.3.1: OCI Object Storage로 이동

먼저 아래의 그림 2-1과 같이 Object Storage 및 Archive Storage로 이동합니다.

1. 브라우저 컨텍스트가 영역 1(애슈번)로 설정되었는지 확인합니다.
2. 스토리지 선택.
3. 버킷 선택.

그림 2-1: 객체 스토리지로 이동

작업 2.3.2: 영역 1의 OCI 스토리지 버킷

영역 1에서 Object Storage 버킷을 생성합니다. 버킷은 이후 단계에서 영역 1의 DR 보호 그룹에 지정됩니다.

1. OIC 관련 리소스를 포함하는 구획을 선택합니다.
2. Create Bucket을 선택합니다.
3. 버킷이 어떤 애플리케이션과 용도를 제공하는지 쉽게 식별할 수 있는 의미 있는 이름을 버킷에 제공합니다. 이름의 일부로 리전을 포함할 이유는 없습니다. 예를 들어, 이 이름은 OIC에 대한 DR 작업과 관련된 OCI 전체 스택 DR 로그에 사용됨을 나타냅니다.
4. 계층 및 암호화에 기본값을 사용합니다.
5. Create를 선택하여 버킷을 생성합니다.

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

작업 2.3.3: 영역 2의 OCI 스토리지 버킷

동일한 프로세스에 따라 영역 2(피닉스)에서 오브젝트 스토리지 버킷을 생성합니다. 버킷은 이후 단계에서 영역 2의 DR 보호 그룹에 지정됩니다.

1. 컨텍스트를 영역 2로 변경합니다.
2. 영역 2에서 OIC 관련 리소스를 포함하는 구획을 선택합니다.
3. 영역 1에서 버킷에 할당된 것과 동일한 이름을 사용하십시오. 그러면 이후 단계에서 쉽게 식별할 수 있습니다.
4. Create를 선택하여 버킷을 생성합니다.

그림 2-3: 영역 2에서 오브젝트 스토리지 버킷 생성

작업 3: 두 영역에서 DR 보호 그룹 생성

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

이 애플리케이션 스택에 대한 보호 그룹이 아직 없는 경우 영역 1 및 영역 2에 DR 보호 그룹을 생성합니다.

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

먼저 아래 그림 3-1과 같이 DR 보호 그룹(OCI 전체 스택 DR)으로 이동합니다.

1. OCI 리전 컨텍스트가 리전 1(애슈번)로 설정되었는지 확인합니다.
2. Migration & Disaster Recovery를 선택합니다.
3. DR 보호 그룹을 선택합니다.

그림 3-1: DR 보호 그룹으로 이동

작업 3.2: 영역 1에서 보호 그룹 생성

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

1. DRPG를 생성할 구획을 선택합니다. Oracle Integration 리소스가 존재하는 구획과 동일한 구획일 수도 있고, 이 경우 여러 비즈니스 시스템에 대해 DRPG를 포함하는 저장소 역할을 하는 구획일 수도 있습니다.
2. Create DR protection group을 선택하여 대화 상자를 엽니다.

그림 3-2: 영역 1에서 DR 보호 그룹 생성 시작

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

1. DRPG에 대해 의미 있고 간단한 이름을 사용합니다. 이 예에서는 비즈니스 시스템 이름과 지역을 보여줍니다.
2. 영역 1에 대해 작업 2에서 생성된 오브젝트 스토리지 버킷을 선택합니다.

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

작업 3.3: 영역 2에 보호 그룹 생성

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

1. OCI 영역 컨텍스트를 영역 2로 변경합니다.
2. DRPG를 생성할 구획을 선택합니다. Oracle Integration 리소스가 존재하는 구획과 동일한 구획일 수도 있고, 이 경우 여러 비즈니스 시스템에 대해 DRPG를 포함하는 저장소 역할을 하는 구획일 수도 있습니다.
3. Create DR protection group을 선택하여 대화상자를 엽니다.

그림 3-4: 영역 2에서 DR 보호 그룹 생성 시작

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

1. DRPG에 대해 의미 있고 간단한 이름을 사용합니다. 이 예에서는 비즈니스 시스템 이름과 지역을 보여줍니다.
2. 영역 2의 작업 2에서 생성된 오브젝트 스토리지 버킷 선택

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

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

각 영역의 DRPG를 서로의 피어로 연결하고 기본 및 대기의 피어 역할을 지정합니다. OCI Full Stack DR은 Oracle Integration 복구를 위해 함께 작동하는 두 리전을 파악합니다. 기본 및 대기 롤은 DR 작업/DR 계획 실행의 일부로 OCI 전체 스택 DR에 의해 자동으로 변경되므로 언제든지 수동으로 롤을 관리할 필요가 없습니다.

작업 3.4.1: 연관 시작

1. OCI 지역 컨텍스트가 지역 1(애슈번)로 설정되었는지 확인합니다.
2. Associate를 선택하여 프로세스를 시작합니다.

그림 3-6: DRPG 연관 시작

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

아래 그림 3-7과 같이 매개변수를 제공합니다.

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

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

작업 3.4.3: 연관이 완료된 후 확인해야 할 사항

연관이 완료되면 아래의 그림 3-8과 같이 OCI 전체 스택 DR이 표시됩니다.

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

그림 3-8: 개별 DRPG 관점에서 피어 관계 표시

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

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

그림 3-9: 전역 DRPG 관점에서 피어 관계 표시

작업 4: DR 보호 그룹에 구성원 추가

주: 이 단계에서는 기존 DR 보호 그룹에 멤버를 추가할 때 두 영역의 기존 DR 계획을 모두 삭제합니다. OCI Full Stack DR은 이 쓰기 작업 시 복사본을 저장하거나 DR 보호 그룹을 백업할 수 없습니다. 사용자 정의 계획 그룹 및 단계를 다시 만드는 데 도움이 되도록 DR 계획 그룹 및 단계에 대한 모든 정보를 텍스트 파일 또는 스프레드시트에 기록했는지 확인합니다. 또한 OCI Full Stack DR CLI 명령을 호출하여 사용자 정의 계획 그룹 및 단계를 다시 만드는 bash 스크립트를 만들 수 있습니다(이 자습서의 범위를 벗어남).

DR 제어 노드를 기본 DR 보호 그룹에 멤버로 추가합니다. DR 제어 노드는 Oracle Integration을 제어하기 위해 생성한 컴퓨트 인스턴스이거나 OCI 전체 스택 DR로 관리할 애플리케이션 스택의 일부인 컴퓨트 인스턴스입니다.

다음 리소스를 지역 1의 기본 DRPG에 추가합니다.

1. DR 제어 노드,
2. DR 제어 노드 부트 볼륨을 포함하는 볼륨 그룹입니다.

작업 4.1: 영역 1에서 DRPG에 멤버 추가 시작

아래 그림 4-1과 같이 영역 1에서 DRPG를 선택합니다.

1. OCI 리전 컨텍스트가 리전 1(애슈번)인지 확인합니다.
2. 영역 1에서 DRPG를 선택합니다.
3. 요소 선택.
4. 구성원 추가를 클릭하여 프로세스를 시작합니다.

그림 4-1: 영역 1에서 DR 보호 그룹에 멤버 추가를 시작하는 방법

작업 4.1.1: DR 노드에 대한 컴퓨트 인스턴스 추가

아래 그림 4-2와 같이 DR 제어 노드에 대한 컴퓨트 인스턴스를 추가합니다.

1. DR 계획에 대한 경고를 확인합니다.
2. Compute를 멤버 리소스 유형으로 선택합니다.
3. DR 제어 노드를 사용할 컴퓨트 인스턴스를 선택합니다.
4. 이동 인스턴스를 선택합니다.
5. 복구 중 영역 2에서 VNIC에 지정할 VCN 및 서브넷을 OCI 전체 스택 DR에 지정합니다. 그림 4-2는 단일 VNIC를 보여줍니다. OCI 전체 스택 DR은 보유한 VNIC 수 또는 두 지역 중 하나에서 구성된 방식에 신경 쓰지 않습니다. 요구사항에 맞는 VNIC를 지정하십시오.

그림 4-2: DR 제어 노드를 추가하는 데 필요한 매개변수

작업 4.1.2: DR 노드에 대한 블록 볼륨 그룹 추가

DR 제어 노드에 대한 부트를 포함하는 블록 볼륨 그룹을 추가합니다. 블록 볼륨 그룹에 DR 보호 그룹을 추가하기 전에 두 영역 간에 영역 간 복제가 이미 구성되어 있어야 합니다.

1. 볼륨 그룹을 멤버 리소스 유형으로 선택합니다.
2. 볼륨 그룹을 포함하는 올바른 구획이 선택되었는지 확인한 다음 볼륨 그룹을 선택합니다.

그림 4-3: DR 제어 노드에 대한 부트 볼륨 그룹을 추가하는 데 필요한 매개변수

작업 4.1.3: 영역 1에 대한 멤버 리소스 확인

아래 그림 4-5와 같이 영역 1의 DRPG에는 최소한 두 개의 멤버 리소스가 있어야 합니다. 멤버 리소스의 이름은 서로 다릅니다.

1. OIC DR 제어 노드로 작동하도록 지정한 컴퓨트 인스턴스의 이동식 컴퓨트 인스턴스 및 블록 볼륨 그룹입니다.

그림 4-5: 영역 1에서 DRPG 멤버 표시

컴퓨트 인스턴스를 DR 노드로 이동하여 Oracle Integration 스크립트를 호스트하는 동안 대기 DR 보호 그룹에 멤버를 추가할 필요가 없습니다.

작업 5: 영역 2에서 기본 DR 계획 생성(피닉스)

이 단계에서는 영역 2(피닉스)에서 대기 DR 보호 그룹과 연관된 기본 전환 및 복구 계획을 생성합니다.

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

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

전환 계획은 항상 대기 롤을 가진 보호 그룹에 생성됩니다. 영역 2는 현재 대기 보호 그룹이므로 피닉스에서 시작합니다.

작업 5.1: DR 계획 생성 시작

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

1. OCI 지역 컨텍스트가 리전 2(피닉스)인지 확인합니다.
2. 영역 2에서 대기 DRPG를 선택합니다.
3. 계획 선택.
4. Create Plan을 눌러 프로세스를 시작합니다.

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

작업 5.1.1: 전환 계획 생성

DR 계획 생성은 아래 그림 5-2와 같이 간단합니다.

1. 전환 계획의 이름을 간단하지만 의미 있게 만듭니다. 이 이름은 가능한 한 짧지만 한 눈에 쉽게 이해할 수 있어야 위기 동안 혼란과 인간의 실수를 줄일 수 있습니다.
2. 계획 유형을 선택합니다. 이 문서 작성 시에는 네 가지 계획 유형만 있습니다.

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

작업 5.1.2: 복구 계획 생성

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

1. 페일오버 계획의 이름을 단순하지만 의미 있게 만듭니다. 이 이름은 가능한 한 짧지만 한 눈에 쉽게 이해할 수 있어야 위기 동안 혼란과 인간의 실수를 줄일 수 있습니다.
2. 계획 유형을 선택합니다. 이 문서 작성 시에는 두 가지 계획 유형만 있습니다.

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

이제 영역 2의 대기 DR 보호 그룹에 아래와 같이 두 개의 DR 계획이 있어야 합니다. 이렇게 하면 영역 1에서 영역 2로 작업 로드를 전환할 수 있습니다. 이후 단계에서 영역 1에서 작업 로드를 영역 2에서 영역 1로 다시 전환하는 유사한 계획을 생성합니다.

그림 5-4: 더 진행하기 전에 영역 2에 있어야 하는 두 가지 기본 DR 계획 표시

작업 6: 영역 2의 전환 계획 사용자 정의(피닉스)

작업 5에서 생성된 기본 DR 계획에는 OCI 전체 스택 DR에 내장되어 있으며 Oracle Integration과 관련된 복구 작업을 관리하는 데 필요한 항목이 없는 복구 작업에 대해 미리 채워진 단계가 포함되어 있습니다. 이 단계에서는 사용자정의 DR 계획 그룹을 추가하는 방법과 Oracle Integration 전환 중 수행해야 하는 작업을 관리하는 단계를 설명합니다.

1. 영역 1에서 영역 2로 일정이 잡힌 매개변수 동기화
2. 지역 2에서 관련 통합 활성화
3. 영역 2에서 일정이 잡힌 통합 시작
4. 영역 2에서 DNS 레코드 업데이트
5. 영역 1에서 일정이 잡힌 통합 비활성화

작업 6.1: 전환 계획 선택

먼저 이전 단계에서 생성한 switchover 계획으로 이동합니다.

그림 6-1: 영역 2에서 전환 계획 사용자 정의를 시작하는 방법

작업 6.2: 아티팩트를 종료하는 DR 계획 그룹 사용(선택사항)

아래 스크린샷에 표시된 대로 전환 계획에서 기본적으로 사용 안함으로 설정되는 두 개의 계획 그룹이 있습니다. 테스트 중에 실제로 삭제되는 항목이 없고 테스트 중에 문제가 발생할 경우 백업으로 사용할 수 있는 아티팩트 복사본이 있는 경우 테스트 중에 편안함을 제공하기 위해 비활성화됩니다.

그러나 이러한 두 계획 그룹은 향후 DR 작업의 일부로 다시 사용되지 않을 아티팩트를 종료(삭제)합니다. 두 영역 간에 전환하면 시간이 지남에 따라 아티팩트가 계속 누적되어 실제로 활성화되어야 하는 컴퓨트 인스턴스 및 볼륨 그룹이 무엇인지 혼동하게 됩니다.

OCI Full Stack DR이 프로덕션으로 전환되면 이러한 계획 그룹을 활성화해야 합니다. 전환 및 전환을 테스트하는 동안 두 계획 그룹이 사용 안함으로 설정된 상태로 유지된 아티팩트는 프로덕션으로 전환하기 전에 종료 및 정리해야 정상적인 작업 중 혼동 및 인적 오류가 발생할 가능성을 줄일 수 있습니다.

선택적으로 프로덕션으로 전환하기 전에 불필요한 아티팩트를 수동으로 정리할 필요가 없도록 지금 이러한 계획 그룹을 사용으로 설정할 수 있습니다.

그림 6-2: 기본적으로 사용 안함으로 설정된 계획 그룹

다음은 비활성화된 계획 그룹이 활성화될 때 수행하는 작업입니다.

1. 이 계획 그룹은 OCI 블록 스토리지 작업 중 복제된 VM 버전이 영역 2에서 실행된 후 영역 1에서 남아 있는 컴퓨트 인스턴스의 아티팩트를 종료하여 스위치오버의 일부로 영역 2에서 영역 1로 다시 복제 방향을 바꿉니다. 블록 볼륨 복제 방향 바꾸기 작업이 완전히 새로운 블록 볼륨 그룹에 모든 새 VM을 만들기 때문에 남은 VM은 스위치백 중 사용되지 않습니다.

2. 이 계획 그룹은 복제된 VG 버전이 영역 2에서 활성화되고 전환 중 볼륨 그룹 복제 방향이 바뀐 후 영역 1에서 남아 있는 VG(블록 볼륨 그룹)의 아티팩트를 종료합니다. 남은 블록 볼륨 그룹은 영역 2에서 다시 영역 1로 전환하는 과정이 아니더라도 다시 사용되지 않습니다.

작업 6.2.1: 컴퓨트 계획 그룹 종료를 사용으로 설정합니다.

계획 그룹을 사용으로 설정합니다.

1. 제도 그룹 이름 오른쪽의 컨텍스트 메뉴에서 모든 단계 사용을 선택합니다.

그림 6-3: 컴퓨트 인스턴스 종료를 사용으로 설정하는 방법

작업 6.2.2 볼륨 그룹 종료 계획 그룹 사용

계획 그룹을 사용으로 설정합니다.

1. 제도 그룹 이름 오른쪽의 컨텍스트 메뉴에서 모든 단계 사용을 선택합니다.

그림 6-4: 종료 볼륨 그룹을 사용으로 설정하는 방법

작업 6.3: 영역 1에서 영역 2로 일정이 잡힌 매개변수를 동기화할 계획 그룹 생성

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

첫 번째 사용자 정의 계획 그룹은 영역 1에서 영역으로 스케줄링된 매개변수를 동기화합니다. 이 계획 그룹에는 작업 1.4의 DR 제어 노드로 다운로드된 oic-sync-schedule-parameters.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

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

1. 시작하려면 그룹 추가를 누르십시오.

그림 6-5: 일정이 잡힌 매개변수를 동기화할 계획 그룹 추가 시작

작업 6.3.2: 계획 그룹 이름, 주문 및 추가 단계 제공

DR 계획 그룹에는 모두 병렬로 실행되는 여러 단계가 포함될 수 있습니다. 스케줄링된 매개변수를 동기화하기 위해 bash 스크립트를 실행하는 한 단계만 추가합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 영역 1에서 VM을 중지하는 내장 계획 그룹 전에 사용자 정의 계획 그룹을 삽입하려고 합니다.
3. 내장 컴퓨트 인스턴스 정지(기본) 계획 그룹을 선택합니다.
4. 단계 추가를 눌러 스케줄링된 매개변수를 동기화할 스크립트를 지정할 대화상자를 엽니다.

그림 6-6: 계획 그룹을 생성하고 일정이 잡힌 매개변수 동기화를 위한 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 영역 1에서 영역 2로 일정이 잡힌 매개변수를 동기화합니다.

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

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. 스위치오버 중 DR 제어 노드가 실행될 영역이 실행되지 않는 영역을 항상 선택하십시오. OCI Full Stack DR은 VM의 실행 위치를 추적하므로 현재 위치를 지정하기만 하면 됩니다. 이 경우 DR 제어 노드는 영역 1(애슈번)에서 실행 중입니다.
3. 로컬 스크립트 실행을 선택하여 컴퓨트 인스턴스에서 스크립트를 찾을 수 있음을 OCI 전체 스택 DR에 알립니다. bash 스크립트는 작업 1.3의 DR 제어 노드로 다운로드되었습니다.
4. DR 제어 노드를 포함하는 올바른 구획을 선택합니다. 모든 구획일 수 있습니다. DR 제어 노드로 지정된 컴퓨트 인스턴스를 선택합니다(이 프로젝트/자습서용으로만 생성된 애플리케이션 서버 또는 VM일 수 있음).
5. DR 제어 노드에서 oic-sync-schedule-parameters.sh 스크립트를 설치한 절대 경로를 붙여 넣습니다. 매개변수로 PHX를 추가하십시오. 스케줄링된 매개변수를 동기화할 대상 영역입니다. 서로 다른 OCI 리전을 사용하고 스크립트를 업데이트하는 경우 올바른 리전 매개변수를 제공해야 할 수 있습니다.
6. 스크립트를 실행할 사용자로 opc를 지정합니다.
7. 스크립트가 예약된 매개변수를 동기화하지 못하면 DR 계획이 중지되어야 합니다. 그러면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후 전환 계획을 계속 실행할 수 있는 기회를 제공합니다.
8. OCI 전체 스택 DR이 실패를 선언하기 전의 기본값은 1시간입니다. 이 값은 30분으로 변경하거나 보다 현실적인 시간 초과 값이 될 수 있습니다.
9. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 6-7: 일정이 잡힌 매개변수 동기화에 대한 계획 단계를 생성하는 매개변수

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

이제 아래 그림 6-8과 같이 동기화 예약된 매개변수의 중지 단계가 DR 계획 그룹에 추가되었습니다.

1. 방금 추가된 계획 단계가 표시됩니다. DR 계획 그룹에 단계를 더 추가할 수 있지만 이 계획 그룹에는 일정이 잡힌 매개변수를 동기화하는 단계만 포함됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 6-8: 계획 그룹 및 단계 추가를 완료하여 일정이 잡힌 매개변수 동기화

작업 6.4: 대기 상태에서 관련 통합을 활성화할 계획 그룹 생성

두번째 사용자 정의 계획 그룹은 DR 제어 노드가 대기 영역 2에서 실행된 후 대기에서 관련 통합을 활성화합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 oic-integration-switch.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 6-9: 대기 상태에서 관련 통합을 활성화하기 위해 계획 그룹 추가를 시작합니다.

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

DR 계획 그룹을 생성하여 대기에서 관련 통합을 활성화합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 영역 2에서 복제된 DR 제어 노드 버전을 실행하는 내장 계획 그룹 후에 사용자 정의 계획 그룹을 삽입하려고 합니다.
3. 내장 컴퓨트 인스턴스 실행(대기) 계획 그룹 선택
4. 대기 시 관련 통합을 활성화할 스크립트를 지정할 대화상자를 열려면 단계 추가를 누릅니다.

그림 6-10: 계획 그룹을 생성하고 대기 데이터베이스에서 관련 통합을 활성화하는 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 지역 2에서 관련 통합을 활성화합니다.

이 단계의 모든 사항은 아래의 그림 6-11에 표시된 항목을 제외하고 Task 6.3.3과 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 oic-integration-switch.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. activate를 첫번째 매개변수로 추가하고 PHX를 second.This는 관련 통합을 활성화할 대상 영역입니다. 서로 다른 OCI 리전을 사용하고 스크립트를 업데이트하는 경우 올바른 리전 매개변수를 제공해야 할 수 있습니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 6-11: 대기 데이터베이스에서 관련 통합을 활성화하기 위한 계획 단계를 생성하는 매개변수

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

이제 아래 그림 6-12와 같이 대기에서 관련 통합을 활성화하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 6-12: 대기 데이터베이스에서 관련 통합을 활성화하기 위한 계획 그룹 및 단계 추가를 완료합니다.

작업 6.5: 영역 2에서 일정이 잡힌 통합을 시작할 계획 그룹 생성

세번째 사용자 정의 계획 그룹은 DR 제어 노드가 대기 영역 2에서 실행된 후 대기에서 일정이 잡힌 통합을 시작합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 oic-integration-schedule.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 6-13: 대기에서 일정이 잡힌 통합을 시작할 계획 그룹 추가 시작

작업 6.5.2: 계획 그룹 이름, 주문 및 추가 단계 제공

대기 영역 2에서 일정이 잡힌 통합을 시작할 DR 계획 그룹을 생성합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 이전 태스크에서 생성된 사용자 정의 계획 그룹 후에 사용자 정의 계획 그룹을 삽입하여 관련 통합을 활성화합니다.
3. 내장 대기 시 관련 통합 활성화 계획 그룹을 선택합니다.
4. 대기에서 일정이 잡힌 통합을 시작할 스크립트를 지정할 대화상자를 열려면 단계 추가를 누릅니다.

그림 6-14: 계획 그룹을 생성하고 대기에서 일정이 잡힌 통합을 시작하기 위한 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 대기 영역 2에서 일정이 잡힌 통합을 시작합니다.

이 작업의 모든 내용은 아래의 그림 6-15에 표시된 항목을 제외하고 작업 6.3.3과 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 oic-integration-schedule.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. start를 첫번째 매개변수로 추가하고 PHX를 두번째 매개변수로 추가합니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 6-15: 대기에서 일정이 잡힌 통합을 시작하기 위한 계획 단계를 생성하는 매개변수입니다.

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

이제 아래 그림 6-16과 같이 대기에서 예약된 통합을 시작하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 6-16: 계획 그룹 추가를 완료하고 대기 상태에서 일정이 잡힌 통합을 시작합니다.

작업 6.6: 영역 2에서 DNS 레코드를 업데이트할 계획 그룹 생성

네번째 사용자 정의 계획 그룹은 DR 제어 노드가 대기 영역 2에서 실행된 후 대기에서 DNS 레코드를 업데이트합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 dns_record_update.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 6-17: 대기 데이터베이스에서 DNS 레코드를 업데이트할 계획 그룹 추가를 시작합니다.

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

DR 계획 그룹을 생성하여 DNS 레코드를 영역 2로 업데이트합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 내장 계획 그룹 이후 사용자 정의 계획 그룹을 삽입하여 대기에서 일정이 잡힌 통합을 시작합니다.
3. 내장 대기에서 일정이 잡힌 통합 시작 계획 그룹을 선택합니다.
4. 단계 추가를 눌러 대기 시 DNS 레코드를 업데이트할 스크립트를 지정할 대화상자를 엽니다.

그림 6-18: 계획 그룹을 생성하고 대기 데이터베이스에서 DNS 레코드를 업데이트하는 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 대기 데이터베이스에서 DNS 레코드를 업데이트합니다.

이 작업의 모든 내용은 아래의 그림 6-19에 표시된 항목을 제외하고 작업 6.3.3과 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 dns_record_update.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. region 2(이 예제에서는 PHX)에 대한 OCI 리전 키를 매개변수로 추가합니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 6-19: 대기 데이터베이스에서 DNS 레코드를 업데이트하는 계획 단계를 생성하는 매개변수입니다.

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

이제 아래 그림 6-20과 같이 대기에서 DNS 레코드를 업데이트하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 6-20: 대기 데이터베이스에서 DNS 레코드를 업데이트하기 위한 계획 그룹 및 단계 추가를 완료합니다.

작업 6.7: 영역 1에서 일정이 잡힌 통합을 비활성화할 계획 그룹 생성

최종 사용자 정의 계획 그룹은 DR 제어 노드가 대기 영역 2에서 실행된 후 영역 1에서 일정이 잡힌 통합을 비활성화합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 oic-integration-switch.sh 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 6-21: 영역 1에서 일정이 잡힌 통합을 비활성화할 계획 그룹 추가를 시작합니다.

작업 6.7.2: 계획 그룹 이름, 주문 및 추가 단계 제공

DR 계획 그룹을 생성하여 영역 1에서 일정이 잡힌 통합을 비활성화합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 내장 계획 그룹 이후 사용자 정의 계획 그룹을 삽입하여 대기 중인 DNS 레코드를 업데이트합니다.
3. 내장 대기 상태의 DNS 레코드 업데이트 계획 그룹을 선택합니다.
4. 단계 추가를 눌러 영역 1에서 일정이 잡힌 통합을 비활성화하는 스크립트를 지정할 대화상자를 엽니다.

그림 6-22: 영역 1에서 계획 그룹을 생성하고 일정이 잡힌 통합을 비활성화하는 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 영역 1에서 일정이 잡힌 통합을 비활성화합니다.

이 작업의 모든 내용은 아래의 그림 6-23에 표시된 항목을 제외하고 작업 6.3.3과 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 oic-integration-switch.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. region 1(이 예제에서는 IAD)에 대한 OCI 리전 키를 매개변수로 추가합니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 6-23: 영역 1에서 일정이 잡힌 통합을 비활성화하는 계획 단계를 생성하는 매개변수

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

이제 아래 그림 6-20과 같이 영역 1에서 예약된 통합을 비활성화하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 6-24: 영역 1에서 일정이 잡힌 통합을 비활성화하는 계획 그룹 및 단계 추가를 완료합니다.

이제 전환 계획에는 아래 스크린샷에 표시된 대로 Oracle Integration용 DR 계획 그룹 5개가 포함되어야 합니다. 보호 그룹에 Oracle Integration과 함께 다른 애플리케이션 또는 기타 OCI 서비스가 포함된 경우 추가 계획 그룹이 있을 수 있습니다.

그림 6-25: 전환 계획에 추가된 다섯 개의 사용자 정의 계획 그룹 표시

작업 7: 영역 2에서 페일오버 계획 사용자 정의(피닉스)

이 작업은 사용자 정의 DR 계획 그룹을 추가하는 방법 및 영역 1에 대한 실제 중단 또는 액세스 손실 중에 영역 2에서 Oracle Integration에 대한 페일오버 중 수행해야 하는 작업을 관리하기 위한 단계를 설명합니다. 위 작업 6의 전환 계획에 방금 추가된 동일한 단계의 하위 집합이 됩니다. 그러나 대기 영역 2에서 실행되는 단계만 페일오버 중에 영역 1에 완전히 액세스할 수 없다고 가정하므로 페일오버 계획에 추가됩니다.

1. 지역 2에서 관련 통합 활성화
2. 영역 2에서 일정이 잡힌 매개변수 업데이트
3. 영역 2에서 일정이 잡힌 통합 시작
4. 영역 2에서 DNS 레코드 업데이트

작업 7.1: 복구 계획 선택

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

1. 대기 영역 2가 여전히 콘솔의 현재 영역 컨텍스트인지 확인합니다.
2. 페일오버 계획을 선택합니다.

그림 7-1: 영역 2에서 페일오버 계획을 사용자 정의하는 시작을 생성하는 방법

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

첫 번째 사용자 정의 계획 그룹은 영역 2에서 관련 통합을 활성화합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 oic-integration-switch.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

1. 시작하려면 그룹 추가를 누르십시오.

그림 7-2: 관련 통합을 활성화하기 위해 계획 그룹 추가를 시작합니다.

작업 7.2.1: 계획 그룹 이름, 주문 및 추가 단계 제공

DR 계획 그룹에는 모두 병렬로 실행되는 여러 단계가 포함될 수 있습니다. Bash 스크립트를 실행하여 관련 통합을 활성화하기 위한 한 단계만 추가합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 영역 2에서 복제된 VM을 실행하는 내장 계획 그룹 이후 사용자 정의 계획 그룹을 삽입하려고 합니다.
3. 내장 컴퓨트 인스턴스 실행(대기) 계획 그룹 선택
4. 단계 추가를 눌러 관련 통합을 활성화할 스크립트를 지정할 대화상자를 엽니다.

그림 7-3: 계획 그룹을 생성하고 대기 데이터베이스에서 관련 통합을 활성화하는 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 아래 그림 7-4와 같이 지역 2에서 관련 통합을 활성화합니다.

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

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. 스크립트가 관련 통합을 활성화하지 못하면 DR 계획이 중지되어야 합니다. 그러면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제 해결 후 전환 계획을 계속 실행할 수 있는 기회를 제공합니다.
3. OCI 전체 스택 DR이 실패를 선언하기 전의 기본값은 1시간입니다. 이 값은 30분으로 변경하거나 보다 현실적인 시간 초과 값이 될 수 있습니다.
4. 스위치오버 중 DR 제어 노드가 실행될 영역이 실행되지 않는 영역을 항상 선택하십시오. OCI Full Stack DR은 VM의 실행 위치를 추적하므로 현재 위치를 지정하기만 하면 됩니다. 이 경우 DR 제어 노드는 영역 1(애슈번)에서 실행 중입니다.
5. 로컬 스크립트 실행을 선택하여 컴퓨트 인스턴스에서 스크립트를 찾을 수 있음을 OCI 전체 스택 DR에 알립니다. bash 스크립트는 작업 1.3의 DR 제어 노드로 다운로드되었습니다.
6. DR 제어 노드를 포함하는 올바른 구획을 선택합니다. 모든 구획일 수 있습니다. DR 제어 노드로 지정된 컴퓨트 인스턴스를 선택합니다(이 프로젝트/자습서용으로만 생성된 애플리케이션 서버 또는 VM일 수 있음).
7. DR 제어 노드에서 oic-integration-switch.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. activate를 첫번째 매개변수로 추가하고 PHX를 두번째 매개변수로 추가합니다.
8. 스크립트를 실행할 사용자로 opc를 지정합니다.
9. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 7-4: 대기 데이터베이스에서 관련 통합을 활성화하기 위한 계획 단계를 생성하는 매개변수

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

이제 아래 그림 7-5와 같이 관련 통합을 활성화하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 7-5: 관련 통합을 활성화하기 위한 계획 그룹 및 단계 추가 완료

작업 7.3: 영역 2에서 일정이 잡힌 매개변수를 업데이트할 계획 그룹 생성

두번째 사용자 정의 계획 그룹은 대기 영역 2에서 스케줄링된 매개변수를 업데이트합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 oic-update-parameters.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 7-6: 대기 상태에서 계획 그룹을 추가하여 일정이 잡힌 매개변수를 업데이트합니다.

작업 7.3.2: 계획 그룹 이름, 주문 및 추가 단계 제공

영역 2에서 일정이 잡힌 매개변수를 업데이트할 DR 계획 그룹을 생성합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 이전 태스크에서 생성된 사용자 정의 계획 그룹 후에 사용자 정의 계획 그룹을 삽입하여 관련 통합을 활성화합니다.
3. 대기 시 관련 통합 활성화 계획 그룹을 선택합니다.
4. 대기 시 스케줄링된 매개변수를 업데이트할 스크립트를 지정할 대화상자를 열려면 단계 추가를 누릅니다.

그림 7-7: 계획 그룹을 생성하고 대기 데이터베이스에서 일정이 잡힌 매개변수를 업데이트하는 단계를 추가하는 매개변수

작업 7.3.3: 단계 이름 및 로컬 스크립트 매개변수를 제공합니다.

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 영역 2에서 업데이트 일정이 잡힌 매개변수를 복구합니다.

이 작업의 모든 내용은 아래의 그림 7-8에 표시된 항목을 제외하고 작업 7.3.2와 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 oic-update-parameters.sh 스크립트를 설치한 절대 경로를 붙여 넣습니다. PHX를 유일한 매개변수(이 예의 경우 PHX)로 추가합니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 7-8: 대기 데이터베이스에서 일정이 잡힌 매개변수를 업데이트하기 위한 계획 단계를 생성하는 매개변수

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

이제 아래 그림 7-9와 같이 대기에서 예약된 매개변수를 업데이트하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 7-9: 대기에서 계획 그룹 추가 및 단계 업데이트 일정이 잡힌 매개변수 완료

작업 7.4: 영역 2에서 일정이 잡힌 통합을 시작할 계획 그룹 생성

세번째 사용자 정의 계획 그룹은 DR 제어 노드가 대기 영역 2에서 실행된 후 대기에서 일정이 잡힌 통합을 시작합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 oic-integration-schedule.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 7-10: 대기에서 일정이 잡힌 통합을 시작할 계획 그룹 추가 시작

작업 7.4.2: 계획 그룹 이름, 주문 및 추가 단계 제공

대기 상태에서 일정이 잡힌 통합을 시작할 DR 계획 그룹 생성

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 대기 계획 그룹에서 스케줄링된 매개변수 업데이트 후 사용자 정의 계획 그룹을 삽입하려고 합니다.
3. 내장 대기 시 스케줄링된 매개변수 업데이트 계획 그룹을 선택합니다.
4. 대기에서 일정이 잡힌 통합을 시작할 스크립트를 지정할 대화상자를 열려면 단계 추가를 누릅니다.

그림 7-11: 계획 그룹을 생성하고 대기에서 일정이 잡힌 통합을 시작하기 위한 단계를 추가하는 매개변수

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

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

이 작업의 모든 내용은 아래의 그림 6-19에 표시된 항목을 제외하고 작업 7.2.2와 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 oic-integration-schedule.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. start를 첫번째 매개변수로 추가하고 PHX를 두번째 매개변수로 추가합니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 7-12: 대기에서 일정이 잡힌 통합을 시작하기 위한 계획 단계를 생성하는 매개변수입니다.

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

이제 아래 그림 7-13과 같이 대기에서 예약된 통합을 시작하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 7-13: 대기에서 일정이 잡힌 통합을 시작하기 위한 계획 그룹 및 단계 추가를 완료합니다.

작업 7.5: 영역 2에서 DNS 레코드를 업데이트할 계획 그룹 생성

네번째 사용자 정의 계획 그룹은 DR 제어 노드가 대기 영역 2에서 실행된 후 대기에서 DNS 레코드를 업데이트합니다. 이 계획 그룹에는 작업 1.3의 DR 제어 노드로 다운로드된 dns_record_update.sh bash 스크립트를 호출하는 단일 단계가 포함됩니다.

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

이전과 마찬가지로 그룹 추가를 눌러 시작합니다.

그림 7-14: 대기 데이터베이스에서 DNS 레코드를 업데이트할 계획 그룹 추가를 시작합니다.

작업 7.5.2: 계획 그룹 이름, 주문 및 추가 단계 제공

DR 계획 그룹을 생성하여 DNS 레코드를 영역 2로 업데이트합니다.

1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 내장 계획 그룹 이후 사용자 정의 계획 그룹을 삽입하여 대기에서 일정이 잡힌 통합을 시작합니다.
3. 내장 대기에서 일정이 잡힌 통합 시작 계획 그룹을 선택합니다.
4. 단계 추가를 눌러 대기 시 DNS 레코드를 업데이트할 스크립트를 지정할 대화상자를 엽니다.

그림 7-14: 계획 그룹을 생성하고 대기 데이터베이스에서 DNS 레코드를 업데이트하는 단계를 추가하는 매개변수

작업 7.5.3: 단계 이름 및 로컬 스크립트 매개변수를 제공합니다.

계획 그룹 추가 단계 대화상자에서는 이 한 단계에서 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 대기 데이터베이스에서 DNS 레코드를 업데이트합니다.

이 작업의 모든 내용은 아래의 그림 7-15에 표시된 항목을 제외하고 작업 6.3.3과 동일합니다.

1. 이 단계에서 수행하는 작업을 설명하는 설명이 포함된 이름입니다.
2. DR 제어 노드에서 dns_record_update.sh 스크립트를 설치한 절대 경로를 붙여넣습니다. region 2(이 예제에서는 PHX)에 대한 OCI 리전 키를 매개변수로 추가합니다.
3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

그림 7-15: 대기 데이터베이스에서 DNS 레코드를 업데이트하는 계획 단계를 생성하는 매개변수입니다.

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

이제 아래 그림 7-16과 같이 대기에서 DNS 레코드를 업데이트하는 단계가 DR 계획 그룹에 추가됩니다.

1. 방금 추가된 계획 단계가 표시됩니다.
2. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

그림 7-16: 대기 데이터베이스에서 DNS 레코드를 업데이트하기 위한 계획 그룹 및 단계 추가를 완료합니다.

이제 페일오버 계획에는 아래 스크린샷과 같이 Oracle Integration용 DR 계획 그룹 4개가 포함되어야 합니다. 보호 그룹에 Oracle Integration과 함께 다른 애플리케이션 또는 OCI 서비스가 포함된 경우 추가 계획 그룹이 있을 수 있습니다.

그림 7-14: 페일오버 계획에 추가된 네 개의 사용자 정의 계획 그룹 표시

작업 8: 영역 2에서 switchover 계획 실행(피닉스)

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

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

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

작업 8.1: 계획 실행 시작

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

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

그림 8-1: 대기 영역으로 전환을 실행하는 방법 표시

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

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

1. 전환 계획을 선택합니다.
2. Enable prechecks가 선택되었는지 확인합니다.
3. DR 계획 실행을 눌러 시작합니다.

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

작업 8.3: 다음 단계

Oracle Integration 작업 로드가 영역 1에서 영역 2로 완전히 전환될 때까지 전환 계획을 모니터합니다. OCI Full Stack DR은 아티팩트를 정리하고 영역 간 기본 및 대기 롤을 변경합니다.

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

작업 9: 영역 1에서 DR 계획 생성(애슈번)

이제 대기 피어인 영역 1(애슈번)에 대한 DR 보호 그룹에서 동일한 기본 전환 및 페일오버 계획을 만듭니다.

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

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

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

작업 9.1: DR 계획 생성 시작

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

1. OCI 리전 컨텍스트가 리전 1(애슈번)인지 확인합니다.
2. 영역 1에서 대기 DRPG를 선택합니다.
3. 계획 선택.
4. Create Plan을 눌러 프로세스를 시작합니다.

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

작업 9.1.1: 전환 계획 생성

DR 계획 생성은 아래 그림 9-2와 같이 간단합니다.

1. 전환 계획의 이름을 간단하지만 의미 있게 만듭니다. 이 이름은 가능한 한 짧지만 한 눈에 쉽게 이해할 수 있어야 위기 동안 혼란과 인간의 실수를 줄일 수 있습니다.

2. 계획 유형을 선택합니다. 이 문서 작성 시에는 두 가지 계획 유형만 있습니다.

   
   그림 9-2: DR 전환 계획을 생성하는 데 필요한 매개변수

3. [생성]을 눌러 기본 내장 단계로 미리 채워진 기본 전환 계획을 생성합니다.

작업 9.2: 페일오버 계획 만들기

아래 그림 9-3과 같이 동일한 프로세스에 따라 기본 페일오버 계획을 만듭니다.

1. 페일오버 계획의 이름을 단순하지만 의미 있게 만듭니다. 이 이름은 가능한 한 짧지만 한 눈에 쉽게 이해할 수 있어야 위기 동안 혼란과 인간의 실수를 줄일 수 있습니다.

2. 계획 유형을 선택합니다. 이 문서 작성 시에는 두 가지 계획 유형만 있습니다.

3. [생성]을 눌러 기본 내장 단계로 미리 채워진 기본 복구 계획을 생성합니다.

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

이제 영역 1의 대기 DR 보호 그룹에 아래와 같이 두 개의 DR 계획이 있어야 합니다. 이렇게 하면 영역 2에서 영역 1로 작업 로드를 전환할 수 있습니다.

그림 9-4: 더 진행하기 전에 영역 2에 있어야 하는 두 가지 기본 DR 계획 표시

작업 10: 영역 1의 전환 계획 사용자 정의(애슈번)

이 작업에 대한 모든 작업은 영역 2에 대해 작업 6에서 수행한 작업과 거의 동일합니다. 단, 이 작업은 영역 1에서 수행됩니다.

작업 9에서 생성된 기본 DR 계획에는 Oracle Integration과 관련된 복구 작업을 관리하는 데 필요한 항목이 없습니다. 이 작업에서는 사용자정의 DR 계획 그룹을 추가하는 방법과 Oracle Integration 전환 중 수행해야 하는 작업을 관리하는 단계에 대해 설명합니다.

1. 영역 1에서 영역 2로 스케줄링된 매개변수를 동기화합니다.
2. 지역 2에서 관련 통합을 활성화합니다.
3. 영역 2에서 일정이 잡힌 통합을 시작합니다.
4. 영역 2에서 DNS 레코드를 업데이트합니다.
5. 영역 1에서 일정이 잡힌 통합을 비활성화합니다.

작업 10.1: 전환 계획 선택

먼저 이전 단계에서 생성한 switchover 계획으로 이동합니다.

그림 10-1: 영역 1에서 전환 계획 사용자 정의를 시작하는 방법

작업 10.2: 아티팩트를 종료하는 DR 계획 그룹 사용(선택사항)

이러한 단계는 이전 단계에서 영역 2에 대해 수행된 것과 동일하며 영역 1에 대해 동일한 프로세스를 따라야 합니다.

아래 스크린샷에 표시된 대로 전환 계획에서는 두 개의 계획 그룹이 기본적으로 사용 안함으로 설정됩니다. 테스트 중에 실제로 삭제되는 항목이 없다는 편안함을 제공하기 위해 비활성화되어 있으며, 테스트 중에 문제가 발생할 경우 백업으로 아티팩트의 실행 가능한 복사본이 남아 있습니다.

그러나 이러한 두 계획 그룹은 향후 DR 작업의 일부로 다시 사용되지 않을 아티팩트를 종료(삭제)합니다. 두 영역 간에 전환하면 시간이 지남에 따라 아티팩트가 계속 누적되어 실제로 활성화되어야 하는 컴퓨트 인스턴스 및 볼륨 그룹이란 인간에게 혼란을 야기합니다.

OCI Full Stack DR이 프로덕션으로 전환되면 이러한 계획 그룹을 활성화해야 합니다. 전환 및 전환을 테스트하는 동안 두 계획 그룹이 사용 안함으로 설정된 상태로 유지된 아티팩트는 프로덕션으로 전환하기 전에 종료 및 정리해야 정상적인 작업 중 혼동 및 인적 오류가 발생할 가능성을 줄일 수 있습니다.

선택적으로 프로덕션으로 전환하기 전에 불필요한 아티팩트를 수동으로 정리할 필요가 없도록 지금 이러한 계획 그룹을 사용으로 설정할 수 있습니다.

그림 10-2: 기본적으로 사용 안함으로 설정된 계획 그룹

다음은 비활성화된 계획 그룹이 활성화될 때 수행하는 작업입니다.

1. 이 계획 그룹은 OCI 블록 스토리지 작업 중 복제된 VM 버전이 영역 1에서 실행된 후 영역 2에 남아 있는 컴퓨트 인스턴스의 아티팩트를 종료하여 스위치오버의 일부로 영역 1에서 영역 2로 복제 방향을 바꿉니다. 블록 볼륨 복제 방향 바꾸기 작업이 완전히 새로운 블록 볼륨 그룹에 모든 새 VM을 만들기 때문에 남은 VM은 스위치백 중 사용되지 않습니다.

2. 이 계획 그룹은 복제된 VG 버전이 영역 1에서 활성화되고 스위치오버 중 볼륨 그룹 복제 방향이 바뀐 후 영역 2에서 남아 있는 VG(블록 볼륨 그룹)의 아티팩트를 종료합니다. 남은 블록 볼륨 그룹은 영역 1에서 다시 영역 2로 전환하는 과정이 아니더라도 다시 사용되지 않습니다.

작업 10.2.1: 컴퓨트 계획 그룹 종료를 사용으로 설정합니다.

계획 그룹을 사용으로 설정합니다.

1. 계획 그룹 이름 오른쪽의 컨텍스트 메뉴에서 모든 단계 사용을 선택합니다.

그림 10-3: 컴퓨트 인스턴스 종료를 사용으로 설정하는 방법

작업 10.2.2 볼륨 그룹 종료 계획 그룹 사용

계획 그룹을 사용으로 설정합니다.

1. 계획 그룹 이름 오른쪽의 컨텍스트 메뉴에서 모든 단계 사용을 선택합니다.

그림 10-4: 종료 볼륨 그룹을 사용으로 설정하는 방법

작업 10.3: 전환 계획에 대한 다양한 사용자 정의 계획 생성

작업 6.3에서 6.7로 전환 계획에 대한 다양한 사용자 정의 계획을 생성하는 방법을 이미 설명했습니다. 이와 유사한 프로세스를 사용하여 5개의 사용자정의 계획 그룹을 생성합니다. 스크립트를 실행하려면 피닉스 영역에서 실행 중인 컴퓨트 인스턴스를 사용해야 합니다.

1. 기본에서 대기 /home/opc/oic-scripts/oic-sync-schedule-parameters.sh IAD로 스케줄링된 매개변수를 동기화합니다.
2. 대기 /home/opc/oic-scripts/oic-integration-switch.sh 활성화 IAD에서 관련 통합을 활성화합니다.
3. 대기 /home/opc/oic-scripts/oic-integration-schedule.sh에서 일정이 잡힌 통합을 시작합니다. IAD를 시작합니다.
4. 대기 /home/opc/oic-scripts/dns-record-update.sh IAD에서 DNS 레코드를 업데이트합니다.
5. 기본 /home/opc/oic-scripts/oic-integration-switch.sh에서 일정이 잡힌 통합을 비활성화하면 IAD가 비활성화됩니다.

스위치오버 계획이 생성되면 아래 스크린샷에 표시된 대로 Oracle 통합을 위한 5개의 DR 계획 그룹이 스위치오버 계획에 포함됩니다. 보호 그룹에 Oracle 통합과 함께 다른 애플리케이션 또는 OCI 서비스가 포함된 경우 추가 계획 그룹이 있을 수 있습니다.

그림 10-21: 전환 계획에 추가된 다섯 개의 사용자 정의 계획 그룹 표시

작업 11: 영역 1에서 페일오버 계획 사용자 정의(애슈번)

이 작업은 사용자 정의 DR 계획 그룹을 추가하는 방법 및 영역 2에 대한 실제 중단 또는 액세스 손실 중에 영역 1에서 Oracle Integration에 대한 페일오버 중 수행해야 하는 작업을 관리하는 단계에 대해 설명합니다. 위 작업 10의 전환 계획에 방금 추가된 동일한 단계의 하위 집합이 됩니다. 그러나 대기 영역 1에서 실행되는 단계만 페일오버 중에 영역 2에 완전히 액세스할 수 없다고 가정하므로 페일오버 계획에 추가됩니다.

1. 지역 1에서 관련 통합을 활성화합니다.
2. 영역 1에서 스케줄링된 매개변수를 업데이트합니다.
3. 영역 1에서 일정이 잡힌 통합을 시작합니다.
4. 영역 1에서 DNS 레코드를 업데이트합니다.

작업 11.1: 전환 계획 선택

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

1. 대기 영역 2가 여전히 콘솔의 현재 영역 컨텍스트인지 확인합니다.
2. 페일오버 계획을 선택합니다.

그림 7-1: 영역 2에서 페일오버 계획을 사용자 정의하는 시작을 생성하는 방법

작업 11.2: 영역 1(대기)에서 다중 사용자 정의 계획 그룹 생성

작업 7.2에서 7.5까지 페일오버 계획에 대한 다양한 사용자 정의 계획을 만드는 방법을 이미 설명했습니다. 유사한 프로세스를 사용하여 아래 네 개의 사용자 정의 계획 그룹을 생성합니다. 스크립트를 실행하려면 피닉스 영역에서 실행 중인 컴퓨트 인스턴스를 사용해야 합니다.

1. 대기 /home/opc/oic-scripts/oic-integration-switch.sh 활성화 IAD에서 관련 통합을 활성화합니다.

2. 대기 /home/opc/oic-scripts/oic-update-parameters.sh IAD에서 일정이 잡힌 매개변수를 업데이트합니다.

3. 대기 /home/opc/oic-scripts/oic-integration-schedule.sh에서 일정이 잡힌 통합을 시작합니다. IAD를 시작합니다.

4. 대기 /home/opc/oic-scripts/dns-record-update.sh IAD에서 DNS 레코드를 업데이트합니다.

페일오버 계획이 생성되면 아래 스크린샷에 표시된 대로 Oracle 통합을 위한 DR 계획 그룹 4개가 페일오버 계획에 포함됩니다. 보호 그룹에 Oracle 통합과 함께 다른 애플리케이션 또는 OCI 서비스가 포함된 경우 추가 계획 그룹이 있을 수 있습니다.

그림 11-14: 페일오버 계획에 추가된 네 개의 사용자 정의 계획 그룹 표시

다음 단계

이때 Oracle Integration용 OCI Full Stack DR을 완전히 구현해야 합니다. 그러나 프로덕션에 OCI 전체 스택 DR을 사용하기 전에 전체 기능을 검증해야 합니다. 모든 페일오버 및 스위치오버 계획은 모든 것이 예상대로 작동하는지 검증하고 복구 팀은 전체 프로세스를 완전히 이해합니다.

switchover 계획 테스트

스위치오버 계획은 모든 아티팩트를 정리하고 내장된 복구 단계(예: 로드 밸런서, 블록 스토리지, 파일 시스템, BaseDB, ExaCS 및 자율운영 데이터베이스)에 대한 모든 롤을 사람의 개입 없이 대기 영역에서 복구할 수 있도록 설계되었습니다.

복구 계획 테스트

페일오버는 다릅니다. 특성상 장애 조치는 아티팩트를 정리하거나 실패한 영역의 서비스 및 데이터베이스가 작업 로드를 다시 영역 1로 전환할 준비가 되어 있는지 확인할 수 없습니다. 복구 팀은 Data Guard가 올바른 상태인지, 스토리지 및 컴퓨트 인스턴스에 대한 아티팩트가 종료되었는지 확인하기 위한 작업을 이해하고 수행해야 합니다. 프로세스를 이해하려면 OCI 전체 스택 DR 설명서의 복구 후 DR 구성 재설정을 읽어보십시오.

최종 수락을 위해 모든 DR 계획 검증

복구 팀은 OCI 전체 스택 DR 보호 그룹 및 운용 작업 로드 계획에 대한 준비 상태를 보여주기 위해 최종 검증을 수행해야 합니다. 지역 2(피닉스)는 이 과정에서 현재 기본 지역이어야 합니다. 다음 단계를 완료하여 모든 계획의 최종 검증을 시작합니다.

• 영역 2(기본)에서 영역 1(대기)로 다시 전환을 테스트합니다.

• 영역 1(기본)에서 영역 2(대기)로의 테스트 복구

• 영역 1(기본) 준비 - 영역 2에서 페일오버를 수행합니다.

• 영역 2(기본)에서 영역 1(대기)로 페일오버를 테스트합니다.

• 영역 2 준비(기본) - 페일오버 또는 영역 2로의 스위치오버

• DR 보호 그룹 및 응용 프로그램 스택은 정상 작동 상태여야 하며 이 시점에서 페일오버 또는 스위치오버를 수행할 준비가 되어 있어야 합니다.

참고: 동일한 클라이언트 애플리케이션을 사용하여 두 Oracle Integration 인스턴스에 대한 나머지 API를 인증할 수 있는지 확인하려면 두 인스턴스의 범위(예: 기본 및 보조)를 OAuth 클라이언트 애플리케이션에 추가할 수 있습니다. OAuth 클라이언트 응용 프로그램 설정은 공식 설명서를 참조하십시오.

관련 링크

• 기술 백서: Oracle Integration 2세대용 장애 복구 솔루션 구성

• 샘플 스크립트: GitHub에서 샘플 스크립트를 다운로드합니다.

• YouTube의 OCI 전체 스택 DR Oracle Integration 재생 목록

  • 재해 복구를 위한 Oracle Integration 배포(비디오 1)

  • OCI Full Stack DR을 사용하여 Oracle Integration에 대한 재해 복구 작업 자동화(비디오 2)

  • Oracle Integration의 복구를 자동화하는 데 사용되는 스크립트(동영상 3)

• OCI 전체 스택 장애 복구

• OCI 전체 스택 장애 복구 설명서

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

• #full-stack-dr 공개 슬랙 채널에 참여

확인

• 작성자 - Suraj Ramesh(전체 스택 재해 복구 제품 관리자)

• 공헌자 - Bonnie Rockey(Cloud Engineering, Oracle Integration Specialist), Akshay Saxena(Cloud Engineering, Oracle Integration Specialist)

비디오 1: 재해 복구를 위한 Oracle Integration 배포 비디오 2: OCI Full Stack DR을 사용하여 Oracle Integration에 대한 재해 복구 작업 자동화 비디오 3: Oracle Integration에 대한 복구를 자동화하는 데 사용되는 스크립트

추가 학습 자원

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

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

---

제목 및 저작권 정보

Automate Recovery for Oracle Integration using OCI Full Stack Disaster Recovery

F99107-01

May 2024

Copyright ©2024,

Oracle and/or its affiliates.