주:

OCI Full Stack Disaster Recovery를 사용하여 Oracle Enterprise Performance Management에 대한 자동 복구

파트 1: 소개

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

이 사용지침서에서는 OCI Full Stack DR 서비스를 활용하여 OCI 재해 복구 프레임워크 내에서 Oracle Enterprise Performance Management 시스템 환경 11.1.2.x 및 11.2.x에 대한 스위치오버 및 페일오버 프로세스를 관리하는 절차를 설명합니다. 시스템 토폴로지 및 기타 라이프사이클 활동(패칭, 테스트, 확장 등)의 구성은 OCI Full Stack DR의 범위를 벗어납니다.

DR(재해 복구) 전략은 응용 프로그램에 대한 부트 볼륨과 블록 볼륨을 모두 종합적으로 복제하고, 운용 환경에서 대기 사이트로 데이터베이스용 Oracle Data Guard를 종합적으로 복제하여 대기 위치의 구성을 크게 단순화합니다. 이 방법은 Fusion Middleware에 제공된 재해 복구에 대한 권장 사항을 준수하는 EPM System Deployment Options Guide에 설명된 DR 지침에 따라 정렬됩니다.

Oracle Enterprise Performance Management(Oracle EPM) 및 Hyperion EPM은 자습서와 같은 의미로 사용됩니다.

Oracle Enterprise Performance Management는 일반적으로 대형 시스템의 일부입니다.

이 자습서에서는 Oracle EPM이 DR 보호 그룹에 추가되는 유일한 애플리케이션이라고 가정합니다. 이는 정상적이지 않습니다.

이 자습서에서는 명확성을 위해 Oracle EPM System에만 중점을 둡니다. 실제로 Oracle EPM은 일반적으로 단일 OCI Full Stack DR 보호 그룹 및 DR 계획 세트 내에 다양한 서비스 및 애플리케이션을 포함하는 대규모 비즈니스 시스템의 구성 요소입니다. PeopleSoft,Oracle WebLogic Server,Oracle Analytics Cloud,Oracle Integration과 같은 다른 애플리케이션 및 서비스에 대해 유사한 OHC(Oracle Help Center) 자습서를 따라야 합니다.

증분식 구현에 대한 주의

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

OCI Full Stack DR은 주어진 비즈니스 시스템에 대한 전체 애플리케이션 스택이 이미 OCI 리전에 배포되고, 수동 DR이 이미 작동 중인 것으로 입증되었다는 가정 하에 설계되었습니다. 비즈니스 시스템에 Oracle EPM이 두 개 이상 포함된 경우 DR 계획을 생성하기 전에 다른 모든 애플리케이션 또는 OCI 서비스에 대한 모든 멤버를 DR 보호 그룹에 추가합니다.

복구 작동 방법

Oracle EPM용 복구 솔루션에서는 복구 작업(예: 페일오버 또는 스위치오버) 중에 일련의 사용자정의 셸 스크립트를 실행하기 위해 OCI Full Stack DR이 필요합니다. 이 자습서에서 참조된 스크립트는 EMEA 클라우드 아키텍처 전문가 팀에서 제공하며 이 Hyperion EPM DR 솔루션에 맞게 특별히 조정된 Oracle EPM GitHub 저장소에서 사용할 수 있습니다. 스크립트는 복구 작업 중 OCI Full Stack DR이 관리할 애플리케이션 스택의 일부인 컴퓨트 인스턴스로 다운로드됩니다.

이 자습서에서는 스크립트를 다운로드하는 방법과 이후 단계에서 스크립트를 사용하는 방법에 대해 설명합니다.

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

Oracle EPM 배포 아키텍처

이 자습서에서는 Oracle EPM 애플리케이션의 인스턴스 토폴로지 이동을 사용합니다. 일반적으로 이동 인스턴스를 콜드 VM/파일럿 라이트 DR 토폴로지라고 합니다. 애플리케이션 VM은 기본 영역에만 배치됩니다. DR 런타임 중 VM이 대기 영역에 생성됩니다. Oracle Data Guard가 있는 Oracle DB 시스템을 기본 및 대기 영역에 생성해야 합니다. OCI Full Stack DR 솔루션을 구현하기 전에 기본 Hyperion EPM System을 설치하고 하나의 OCI 리전에 완전히 구성해야 합니다.

이 설계는 OCI 기반 Hyperion에 대한 참조 DR 아키텍처를 기반으로 하며, 이를 자세히 검토할 수 있습니다. 자세한 내용은 클라우드에 Oracle Enterprise Performance Management를 배포할 인프라 설계를 참조하십시오.

프라이빗 OCI 로드 밸런서

내부 및 온프레미스 사용자의 트래픽은 IPSec VPN 터널 또는 FastConnect 가상 회로를 통해 VCN에 연결된 DRG(동적 라우팅 게이트웨이)로 이동합니다. 전용 로드 밸런서는 요청을 가로채서 전용 웹 계층에 배포합니다.

웹 계층은 전용 서브넷에 연결된 컴퓨트 인스턴스에서 호스팅됩니다.

애플리케이션 계층

애플리케이션 계층의 모든 컴퓨트 인스턴스는 전용 서브넷에 연결됩니다. 네트워크 레벨에서 이러한 격리는 응용 프로그램을 토폴로지의 허용되지 않은 네트워크 액세스 및 기타 리소스로부터 보호합니다.

서비스 게이트웨이를 사용하면 애플리케이션 계층의 전용 컴퓨트 인스턴스가 지역 내의 Yum 및 WSUS 서버에 접근하여 운영체제 업데이트 및 추가 패키지를 가져올 수 있습니다. 또한 서비스 게이트웨이를 사용하면 공용 인터넷을 거치지 않고도 지역 내의 OCI Object Storage에 애플리케이션을 백업할 수 있습니다.

블록 볼륨 및 파일 시스템에 저장된 데이터는 CRR(Cross-Region Replication)을 사용하여 대기 영역으로 복제됩니다.

데이터베이스 계층

Oracle Base Database Service는 EPM System 스키마를 호스트합니다. Data Guard를 사용하여 데이터가 대기 영역과 동기화됩니다.

oci-arch-oracle-epm.png
그림 1: Oracle EPM 참조 아키텍처

전체 프로세스 익히기

EMEA OCI 전문가 및 OCI Full Stack DR 엔지니어링 팀은 전체 프로세스 흐름을 파악하기 위한 이 튜토리얼용 컴패니언 비디오 시리즈를 제작했습니다. 이 비디오는 다음 링크를 사용하여 액세스할 수 있는 OCI Full Stack DR Oracle EPM 재생 목록(YouTube)의 일부입니다.

2부: 단계별 지침

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

목표

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

  1. 작업 1: 재해 복구를 위해 Oracle EPM 배포
    1. Oracle Base Database Service용 영역 간 Oracle Data Guard 구성
    2. 사용자정의 자동화를 실행하도록 DR 제어 노드 준비
    3. 블록 볼륨 그룹 생성
    4. Full Stack DR에 대한 Oracle Cloud Infrastructure Identity and Access Management(OCI IAM) 정책 생성
    5. 다른 OCI 서비스에 대한 OCI IAM 정책 생성
    6. 로그에 대한 OCI 오브젝트 스토리지 버킷 생성
    7. 대기 로드 밸런서 생성(선택 사항)
  2. 작업 2: DRPG(DR 보호 그룹) 만들기
  3. 작업 3: 영역 1 및 영역 2 DRPG에 멤버 추가
  4. 작업 4: 영역 2(Newport)에서 기본 DR 계획 생성
    1. 전환 계획 생성
    2. 복구 계획 생성
  5. 작업 5: 영역 2(Newport)에서 switchover 계획 커스터마이즈
  6. 작업 6: 영역 2(Newport)에서 복구 계획 사용자 정의
  7. 작업 7: 영역 2(Newport)에서 switchover 계획 실행
  8. 작업 8: 영역 1(런던)에서 기본 DR 계획 생성
    1. 전환 계획 생성
    2. 복구 계획 생성
  9. 작업 9: 영역 1(런던)에서 switchover 계획 커스터마이즈
  10. 작업 10: 영역 1(런던)에서 Failover 계획 커스터마이즈

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

영역

지역 1 런던

지역 2는 Newport

구획

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

DR 제어 노드

DR 제어 노드는 EPM System을 복구하기 위해 특정 작업을 수행하는 사용자정의 스크립트를 호스트하도록 지정하는 컴퓨트 인스턴스입니다. 복구 작업 중 Full Stack DR에서 스크립트를 호출합니다. DRPG(DR 보호 그룹)의 멤버인 기존 컴퓨트 인스턴스는 제어 노드가 될 수 있습니다. 이 예에서는 EPM System 애플리케이션 서버가 복구 프로세스에 사용되는 모든 사용자정의 스크립트를 호스트합니다. 이 자습서에서는 응용 프로그램 노드와 제어 노드가 모두 동일합니다.

필요 조건

작업 1: 재해 복구를 위해 Oracle EPM 배포

OCI Full Stack DR은 이 단계의 어떤 부분에도 포함되어 있지 않습니다.

작업 1.1: Oracle Base Database Service에 대한 영역 간 Oracle Data Guard 구성

Oracle Base Database Service용 영역 간 Oracle Data Guard를 배치하려면 DB 시스템에서 Oracle Data Guard 사용을 참조하십시오.

시스템의 데이터베이스를 Oracle Data Guard와 동기화할 때는 기본 데이터베이스와 대기 데이터베이스 모두에 대해 동일한 데이터베이스 서비스 이름 또는 TNS 별칭을 사용해야 합니다. 이 연습에서는 스위치오버 후 응용 프로그램 계층에 필요한 변경 사항을 최소화하여 원활한 전환을 보장합니다. 자세한 지침은 다양한 접근 방법에 대해 자세히 설명하는 Fusion Middleware DR 설명서의 "데이터베이스 고려 사항" 절을 참조하십시오.

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

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

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

이 EPM System DR 예에 특별히 작성된 Oracle EPM Github 스크립트를 DR 제어 노드에 다운로드합니다. 아래 표시된 스크립트는 DR 제어 노드로 작동하는 컴퓨트 인스턴스의 하위 디렉토리로 복사해야 합니다. 이 자습서에서는 EPM 앱 노드를 DR 제어 노드로도 사용합니다. 스크립트는 이 EPM System 복구 예를 위해 특별히 생성되었으며 복구 솔루션에서 사용하도록 수정해야 합니다. 이 자습서에서는 EPM 앱이 Windows VM에서 실행 중이므로 Powershell(ps1) 스크립트가 사용됩니다. Linux VM을 사용하는 경우 동일한 github 저장소에서 셸 스크립트를 사용할 수 있습니다. 스크립트를 실행하기 위해 EPM VM을 사용하고 있으므로 DR 제어 노드를 동일한 EPM VM이라고 합니다.

작업 1.3: 블록 볼륨 그룹 생성

영역 1에서 블록 볼륨 그룹을 생성하고 영역 2에서 복제되는지 확인합니다. DR 제어 노드의 부트 볼륨이 블록 볼륨 그룹의 멤버이고 블록 볼륨 그룹이 영역 2로 복제되는지 확인합니다. 자세한 내용은 Creating a Volume Group를 참조하십시오.

이 OCI Full Stack DR 프로젝트의 다른 이동 가능한 컴퓨트에 속하는 다른 부트 및 블록도 리전 2로 복제된 블록 볼륨 그룹에 속해야 합니다.

작업 1.4: OCI Full Stack DR에 대한 OCI IAM 정책 생성

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

작업 1.5: OCI Full Stack DR에서 관리되는 다른 서비스에 대한 OCI IAM 정책 생성

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

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

작업 1.6.1: OCI Object Storage로 이동

그림 1.1과 같이 Object Storage & Archive Storage로 이동하십시오.

  1. 브라우저 컨텍스트가 region 1 (London)로 설정되어 있는지 확인합니다.
  2. 스토리지를 선택합니다.
  3. 버킷 선택.

oss-bucket-nav-lon.png
그림 1.1: 객체 스토리지로 이동합니다.

작업 1.6.2: 영역 1의 OCI 오브젝트 스토리지 버킷

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

  1. EPM System 관련 리소스가 포함된 컴파트먼트를 선택합니다.
  2. 버킷 생성을 누릅니다.
  3. 버킷에 어떤 애플리케이션과 용도를 쉽게 식별할 수 있는 의미 있는 이름을 제공하십시오.
  4. 기본 스토리지 계층 및 암호화에 기본값을 사용합니다.
  5. 생성을 눌러 버킷을 생성합니다.

oss-버킷-생성-lon.png
그림 1.2: 영역 1에서 오브젝트 스토리지 버킷 생성

작업 1.6.3: 영역 2의 OCI Object Storage 버킷

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

  1. 컨텍스트를 영역 2로 변경합니다.
  2. 영역 2의 EPM System 관련 리소스가 포함된 컴파트먼트를 선택합니다.
  3. 생성을 눌러 버킷을 생성합니다.

oss-버킷-생성-lon.png
그림 1.3: 영역 2에서 오브젝트 스토리지 버킷 생성

작업 1.7: (선택사항) 대기 영역에 OCI 로드 밸런서 생성

EPM System에 포함되지 않은 경우 OCI 로드 밸런서 사용은 선택 사항입니다. 이 작업을 건너뜁니다.

Standby Region에서 OCI Load Balancer를 생성합니다.

  1. 기본 로드 밸런서의 구성을 미러링합니다.
  2. 이 로드 밸런서 내에 빈 백엔드 집합을 생성합니다. 대기 영역의 이 시점에는 구성에 포함할 백엔드가 없으므로 빈 백엔드 집합만 생성해야 합니다.

Switchover 또는 Failover 중 구성:

  1. 기본 EPM System 백엔드 집합의 구성이 빈 대기 백엔드 집합으로 복사됩니다.

인증서 및 리스너:

  1. 자체 인증서를 사용하는 경우 대기 로드 밸런서에 로드합니다.
  2. 기본 로드 밸런서 구성과 일치하도록 리스너를 구성합니다.

사후 전환 업데이트:

  1. 전환 후 대기 로드 밸런서의 IP 주소를 가리키도록 DNS 정보를 업데이트합니다.

자세한 내용은 Overview of Load Balancer를 참조하십시오.

작업 2: 두 영역에서 DRPG(DR 보호 그룹) 생성

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

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

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

먼저 아래 그림 2-1과 같이 DR 보호 그룹(OCI Full Stack DR)으로 이동합니다.

  1. OCI 지역 컨텍스트가 지역 1(런던)로 설정되었는지 확인합니다.
  2. 이전 및 재해 복구를 누릅니다.
  3. DR Protection Groups를 누릅니다.

drpg-create-nav-iad.png
그림 2-1: DR 보호 그룹으로 이동합니다.

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

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

  1. DRPG를 생성할 구획을 선택합니다. EPM System 리소스가 존재하는 구획과 동일할 수 있습니다.
  2. DR 보호 그룹 생성을 눌러 대화상자를 엽니다.
  3. DRPG에 의미 있는 이름을 사용합니다.
  4. 영역 1에 대해 작업 2에서 생성된 오브젝트 스토리지 버킷을 선택합니다.
  5. Create를 누릅니다.

drpg-create-완료-lon.png
그림 2.2: 영역 1에서 DR 보호 그룹을 생성하는 데 필요한 매개변수

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

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

  1. OCI 리전 컨텍스트를 리전 2(Newport)로 변경합니다.
  2. DRPG를 생성할 구획을 선택합니다. EPM System 리소스가 존재하는 구획과 동일할 수 있습니다.
  3. DR 보호 그룹 생성을 눌러 대화상자를 엽니다.
  4. DRPG에 의미 있는 이름을 사용합니다.
  5. 영역 2에 대해 작업 2에서 생성된 오브젝트 스토리지 버킷을 선택합니다.
  6. Create를 누릅니다.

drpg-create-완료-newport.png
그림 2-3: 영역 2에서 DR 보호 그룹을 생성하는 데 필요한 매개변수

작업 2.4: 영역 1 및 영역 2의 보호 그룹 연관

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

작업 2.4.1: 연관 시작

  1. OCI 지역 컨텍스트가 지역 1(런던)로 설정되었는지 확인합니다.
  2. 연결을 눌러 프로세스를 시작합니다.

drpg-assoc-begin-lon.png
그림 2.4.1: DRPG 연관 시작

작업 2.4.2: 영역 1 및 영역 2의 보호 그룹 연관

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

  1. 기본 역할을 선택합니다. OCI Full Stack DR은 대기 롤을 리전 2에 자동으로 지정합니다.
  2. 다른 DRPG가 만들어진 영역 2(새 포트)를 선택합니다.
  3. 생성된 피어 DRPG를 선택합니다.
  4. 연계를 누릅니다.

drpg-assoc-finish-lon.png
그림 2.4.2: DRPG를 연관시키는 데 필요한 매개변수

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

연관이 완료되면 OCI Full Stack DR에 그림 2.4.3과 같은 내용이 표시됩니다.

  1. 현재 주 피어 DRPG는 런던(지역 1)입니다.
  2. 현재 대기 피어 DRPG는 Newport(지역 2)입니다.

drpg-assoc-completed-lon.png
그림 2.4.3: 개별 DRPG 관점에서 피어 관계 표시

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

  1. 현재 주 피어 DRPG는 런던(지역 1)입니다.
  2. 현재 대기 피어 DRPG는 Newport(지역 2)입니다.

drpg-assoc-completed-lon.png
그림 2.4.4: 전역 DRPG 관점에서 피어 관계 표시

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

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

데이터베이스 및 Oracle EPM System 애플리케이션 컴퓨트 노드를 DR 보호 그룹의 멤버로 추가합니다. DR 제어 노드는 DR 조정을 지원하기 위해 방금 생성한 컴퓨트 인스턴스이거나, Full Stack DR로 관리할 애플리케이션 스택의 일부인 컴퓨트 인스턴스입니다. 이 예에서 EPM System 애플리케이션 노드는 DR 제어 노드의 기능도 수행합니다.

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

  1. DR 제어 노드의 기능도 수행하는 EPM System 애플리케이션 컴퓨트 노드입니다.
  2. 볼륨 그룹에는 EPM System 애플리케이션 컴퓨트 노드의 부트 볼륨이 포함됩니다. 있는 경우 컴퓨트 노드에 연결된 추가 블록 볼륨이 볼륨 그룹에 포함되어야 합니다.
  3. 기본 Oracle Base Database Service입니다.
  4. 기본 로드 밸런서입니다.

작업 3.1: 영역 1의 DRPG에 멤버 추가 시작

먼저 그림 3-1과 같이 영역 1에서 DRPG를 선택합니다.

  1. OCI 지역 컨텍스트가 지역 1(런던)인지 확인합니다.
  2. 영역 1에서 DRPG를 선택합니다.
  3. 멤버를 선택합니다.
  4. 구성원 추가를 눌러 프로세스를 시작합니다.

drpg-add-nav-lon.png
그림 3-1: 영역 1의 DR 보호 그룹에 멤버를 추가하는 방법

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

그림 3.1.1과 같이 DR 제어 노드 역할을 하는 EPM System의 컴퓨트 인스턴스를 추가합니다. 이 예에서는 단일 컴퓨트 인스턴스가 EPM System의 모든 모듈을 호스트합니다. EPM System이 여러 컴퓨트 노드가 있는 분산 환경에 배포된 경우 각 노드가 이 단계에 포함되어 있는지 확인합니다.

  1. DR 계획에 대한 경고를 수락합니다.
  2. 컴퓨트를 멤버 리소스 유형으로 입력합니다.
  3. EPM System 애플리케이션 컴퓨트 인스턴스를 선택합니다. 이 동일한 컴퓨트 인스턴스가 사용자 정의 스크립트 실행에도 사용됩니다.
  4. 이동 인스턴스를 선택합니다.
  5. 복구 중 영역 2의 VNIC에 지정할 VCN 및 서브넷인 OCI Full Stack DR을 추가합니다. 그림 4-2는 단일 VNIC를 보여줍니다. OCI Full Stack DR은 보유하고 있는 VNIC의 수나 양쪽 리전에서 VNIC를 구성하는 방식에 신경 쓰지 않습니다. 요구 사항에 맞는 VNIC를 지정해 주세요. 대기 영역의 대상 서브넷에서 적합한 IP 주소를 제공해야 합니다. 이렇게 하면 컴퓨트 인스턴스가 동일한 알려진 IP 주소를 일관되게 사용하므로 스위치오버 후 호스트 파일을 간편하게 업데이트할 수 있습니다.

drpg-add-compute-lon.png
그림 3.1.1: DR 제어 노드를 추가하는 데 필요한 매개변수

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

EPM System 애플리케이션 노드에 연결된 부트 및 블록 볼륨이 포함된 블록 볼륨 그룹을 추가합니다. 블록 볼륨 그룹을 DR 보호 그룹에 추가하기 전에 두 영역 간에 영역 간 복제가 이미 구성되어 있어야 합니다.

  1. 볼륨 그룹을 멤버 리소스 유형으로 선택합니다.
  2. 볼륨 그룹을 포함하는 올바른 컴파트먼트가 선택되었는지 확인한 후 볼륨 그룹을 선택하십시오.

drpg-add-vg-lon.png
그림 3.1.2: EPM Compute의 부트 볼륨 그룹을 추가하는 데 필요한 매개변수

작업 3.1.3: 기본 Oracle Base Database Service 추가

이 시점에서 Oracle Data Guard는 작업 1의 일부로 Oracle Base Database 서비스 시스템에 대해 이미 구성되어 있어야 합니다. 영역 1에서 기본 DB를 DRPG의 멤버로 추가합니다.

  1. 데이터베이스를 리소스 유형 멤버로 선택합니다.
  2. 데이터베이스에 대해 올바른 컴파트먼트가 선택되었는지 확인하십시오.
  3. EPM 데이터베이스 SYS 사용자 비밀번호를 포함하는 OCI 저장소의 암호 세부정보를 제공합니다. 작업 1에서 Oracle Data Guard를 구성하는 동안 이 암호를 생성했습니다.

drpg-add-db-lon.png
그림 3.1.3: 기본 DB 서비스에서 실행 중인 기본 DB를 추가하는 데 필요한 매개변수

작업 3.1.4: OCI 로드 밸런서 추가

이 예에서는 로드 밸런서를 영역 1의 DRPG 멤버로 추가합니다.

  1. 로드 밸런서를 리소스 유형 멤버로 선택합니다.
  2. 로드 밸런서에 대해 올바른 구획이 선택되었는지 확인하십시오.
  3. 소스 백엔드 집합: EPM System 애플리케이션에서 사용되는 백엔드 집합입니다. OCI 로드 밸런서는 여러 애플리케이션 간에 공유할 수 있으며 여러 개의 백엔드 집합이 구성되어 있을 수 있습니다. DR 전환 중에는 여기에 지정된 백엔드 집합만 해당 구성이 대기 영역으로 이동됩니다.
  4. 대상 백엔드 집합: 영역 2의 작업 1.7에서 생성된 빈 백엔드 집합입니다.

drpg-add-db-lbr.png
그림 3.1.4: 로드 밸런서를 추가하는 데 필요한 매개변수

작업 3.1.5: 영역 1의 멤버 리소스 확인

이제 그림 3.1.5와 같이 영역 1의 DRPG에 4개의 멤버 리소스가 있어야 합니다. 멤버 리소스의 이름이 달라집니다.

  1. 기본 데이터베이스입니다.
  2. 이동 가능한 컴퓨트 인스턴스입니다.
  3. 컴퓨트 인스턴스에 대한 블록 볼륨 그룹입니다.
  4. OCI 로드 밸런서

drpg-add-finish-lon.png
그림 3.1.5: 영역 1의 DRPG 멤버 표시

작업 3.2: 영역 2의 DRPG에 멤버 추가 시작

먼저 영역 2에서 DRPG를 선택합니다.

  1. OCI 리전 컨텍스트가 리전 2(Newport)인지 확인합니다.
  2. 영역 2에서 DRPG를 선택합니다.
  3. 멤버를 누릅니다.
  4. 구성원 추가를 눌러 프로세스를 시작합니다.

기본 영역과 유사한 단계에 따라 영역 2의 대기 DRPG에 다음 리소스를 추가합니다.

  1. 대기/원격 Oracle Base Database Service 시스템입니다.
  2. 대기 OCI 로드 밸런서.

작업이 완료되면 아래 그림 3.2와 같이 영역 2의 DRPG에 멤버 리소스가 두 개 있어야 합니다.

drpg-add-finish-newport.png
그림 3.2: 영역 2의 DRPG 멤버 표시

작업 4: 영역 2에서 기본 DR 계획 생성(Newport)

이 단계는 영역 2(Newport)의 대기 DR 보호 그룹과 연관된 기본 전환 및 페일오버 계획을 생성합니다.

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

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

switchover 계획은 항상 standby 롤을 사용하여 보호 그룹에 생성됩니다. 영역 2는 현재 standby 보호 그룹이므로 Newport에서 시작됩니다.

작업 4.1: DR 계획 생성

영역 2(Newport)에서 DRPG를 선택하여 기본 계획 생성

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

plan-create-newport-nav.png
그림 4-1: 영역 2에서 기본 DR 계획 생성을 시작하는 방법

작업 4.1.1: 전환 계획 생성

DR 계획을 만드는 작업은 아래 그림 4.1.1과 같이 간단합니다.

  1. switchover 계획의 이름을 단순하지만 의미 있게 만듭니다. 이름은 가능한 한 짧아야하지만 위기 동안 혼란과 인간의 실수를 줄이는 데 도움이되는 한 눈에 이해하기 쉽습니다.
  2. 계획 유형을 전환(계획됨)으로 선택합니다. 이 글을 쓸 때에는 네 가지 계획 유형만 있습니다.

plan-create-newport-so.png
그림 4.1.1: DR 전환 계획을 생성하는 데 필요한 매개변수

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

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

  1. 페일오버 계획의 이름을 단순하지만 의미 있게 만듭니다. 이름은 가능한 한 짧아야하지만 위기 동안 혼란과 인간의 실수를 줄이는 데 도움이되는 한 눈에 이해하기 쉽습니다.
  2. 계획 유형을 페일오버(계획되지 않음)로 선택합니다. 이 글을 쓸 때에는 네 가지 계획 유형만 있습니다.

plan-create-newport-fo.png
그림 4.1.2: DR 복구 계획을 생성하는 데 필요한 매개변수입니다.

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

plan-create-newport-completed.png
그림 4.1.3: 더 이상 진행하기 전에 영역 2에 존재해야 하는 두 가지 기본 DR 계획 표시

작업 5: 영역 2의 전환 계획 사용자 정의(Newport)

태스크 4에서 생성된 기본 DR 계획에는 전체 스택 DR에 내장되어 있으며 EPM System 애플리케이션과 관련된 복구 태스크를 관리할 수 있는 항목이 없는 복구 태스크에 대해 미리 채워진 단계가 포함됩니다. 이 단계에서는 사용자 정의 DR 계획 그룹 및 EPM System에 대한 전환 중 수행해야 하는 태스크를 관리하는 단계를 추가하는 방법에 대해 설명합니다.

작업 5.1: 전환 계획 선택

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

plan-custom-so-newport-nav.png
그림 5.1: 영역 2에서 전환 계획 사용자 정의를 시작하는 방법

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

다음 스크린샷에 나오는 것처럼 switchover 계획에서 기본적으로 비활성화되는 두 개의 계획 그룹이 있습니다. 테스트 중에 아무것도 실제로 삭제되고 있지 않으며 테스트 중에 문제가 발생할 경우 백업으로 아티팩트의 실행 가능한 복사본을 계속 사용할 수 있습니다.

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

OCI Full Stack DR이 프로덕션으로 전환되면 해당 계획 그룹을 활성화해야 합니다. 스위치오버 및 스위치백을 테스트하는 동안 이러한 두 계획 그룹이 사용 안함으로 설정된 동안 제자리에 남아 있던 모든 아티팩트는 운용 단계로 이동하기 전에 종료하고 정리하여 정상적인 작동 중 혼동 및 인적 오류 가능성을 줄여야 합니다.

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

plan-custom-so-newport-disabled-show.png
그림 5.2: 기본적으로 사용 안함으로 설정된 계획 그룹

다음은 사용 안함으로 설정된 계획 그룹이 사용으로 설정될 때 수행하는 작업입니다.

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

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

태스크 5.2.1: 컴퓨트 계획 그룹 종료 사용

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

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

    plan-custom-so-newport-enable-terminate-vm.png
    그림 5.2.1: 컴퓨트 인스턴스 종료를 사용으로 설정하는 방법

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

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

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

    plan-custom-so-newport-enable-terminate-vg.png
    그림 5.2.2: 종료 볼륨 그룹을 사용으로 설정하는 방법

작업 5.3: 영역 1(기본)에서 사용자 정의 스크립트를 실행할 계획 그룹 생성

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

첫 번째 사용자 정의 계획 그룹은 사용자정의 스크립트를 실행하여 기본 영역 1에서 실행되는 EPM System 서비스를 중지합니다. 이 계획 그룹에는 Windows PowerShell 스크립트 stop_services.ps1을 호출하는 단일 단계가 포함됩니다. 이 스크립트는 태스크 1.2의 EPM 애플리케이션 노드에 있는 c:/scripts 폴더로 다운로드됩니다.

태스크 5.3.1: 계획 그룹 추가 선택

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

  1. 시작하려면 그룹 추가를 누르십시오.
  2. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다. 이는 선택 사항이지만 가장 좋은 방법은 계획 그룹이 단계를 실행할 영역에 대한 메모를 추가하는 것입니다.
  3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 영역 1에서 VM을 중지하는 기본 제공 계획 그룹 앞에 사용자 정의 계획 그룹을 삽입합니다.
  4. 기본 제공 계산 인스턴스 정지(기본) 계획 그룹을 선택합니다.
  5. 단계 추가를 눌러 EPM System을 정지할 스크립트를 지정할 수 있는 대화상자를 엽니다.

플랜-custom-so-newport-grp1-name.svg
그림 5.3.1: 계획 그룹을 생성하고 EPM을 정지하기 위한 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 지역 1의 EPM System 서비스가 중지됩니다.

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

  1. 이 단계가 수행하는 작업을 설명하는 단계 이름입니다.
  2. 전환 중 실행될 위치가 아니라 EPM 앱 노드가 지금 실행 중인 영역을 항상 선택합니다. OCI Full Stack DR은 VM이 실행되는 위치를 추적하므로 현재 위치를 지정하기만 하면 됩니다. 이 경우 EPM App 노드가 영역 1(런던)에서 실행됩니다.
  3. DR 제어 노드를 포함하는 올바른 컴파트먼트를 선택합니다. 그런 다음 DR 제어 노드로 지정된 컴퓨트 인스턴스를 선택합니다. 이 예에서는 EPM 시스템 애플리케이션 컴퓨트입니다.
  4. 로컬 스크립트 실행을 선택하여 OCI Full Stack DR에 컴퓨트 인스턴스에서 스크립트를 찾을 수 있음을 알립니다. Windows PowerShell 스크립트가 작업 1.2의 DR 제어 노드로 다운로드되었습니다.
  5. DR 제어 노드에 stop_services.ps1 스크립트를 설치한 절대 경로를 붙여 넣습니다. 첫번째 파라미터로 stop을 추가하고 OCI 지역 ID를 두번째 파라미터로 추가합니다.
  6. 스크립트가 EPM Services를 중지하지 못하면 DR 계획이 중지되어야 합니다. 그러면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. OCI Full Stack DR은 문제를 해결한 후 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.
  7. Full Stack DR이 실패를 선언하기 전의 기본값은 1시간입니다. 이 값은 30분으로 변경하거나 보다 사실적인 시간 초과 값으로 느껴지는 값을 변경할 수 있습니다.
  8. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

플랜-custom-so-newport-grp1-step.png
그림 5.3.2: EPM을 중지하기 위한 계획 단계를 생성하는 매개변수

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

아래 그림 5.3.3과 같이 이제 EPM System 중지 단계가 DR 계획 그룹에 추가되었습니다.

방금 추가된 계획 단계가 표시됩니다. DR 계획 그룹에 단계를 더 추가할 수 있지만 이 계획 그룹에는 EPM 서비스를 중지하는 단계만 포함됩니다. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

플랜-custom-so-newport-grp1-finish.png
그림 5.3.3: EPM을 중지하기 위한 계획 그룹 및 단계 추가를 완료합니다.

작업 5.4: 영역 2(대기)에서 사용자 정의 스크립트를 실행할 계획 그룹 생성

두 번째 사용자 정의 계획 그룹은 대기 영역 2에서 DR 제어 노드가 실행된 후 컴퓨트 노드의 호스트 파일을 업데이트하고 EPM System 서비스를 시작합니다. 이 계획 그룹에는 작업 1.2의 DR 제어 노드로 다운로드된 host_switch_failover.ps1 및 start_services.ps1 PowerShell 스크립트를 호출하는 두 단계가 포함됩니다.

작업 5.4.1 대기 영역으로 전환한 후 호스트 파일을 업데이트할 DR 계획 그룹 생성

  1. 계획 그룹에 단순하지만 설명적인 그룹 이름을 지정합니다.
  2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 EPM System 애플리케이션 노드의 복제된 버전을 실행하는 기본 제공 계획 그룹 뒤에 사용자 정의 계획 그룹을 삽입하여 영역 2에서 DR 제어 노드의 기능도 수행합니다.
  3. 내장 컴퓨트 인스턴스 실행 계획 그룹 선택
  4. 단계 추가를 눌러 호스트 파일을 업데이트할 스크립트를 지정할 수 있는 대화상자를 엽니다.

플랜-custom-so-newport-grp2-step.png
그림 5.4.1: EPM을 시작하기 위한 계획 단계를 생성하는 매개변수

작업 5.4.2: 호스트 파일 업데이트 스크립트에 대한 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. host_switch_failover.ps1 스크립트는 컴퓨트 노드의 호스트 파일을 업데이트하여 영역 2의 컴퓨트 및 데이터베이스 인스턴스에 대한 새 IP 주소가 원래 영역 1 호스트 이름에 매핑되도록 합니다. 이렇게 하면 응용 프로그램 층에서 추가 수정 없이 응용 프로그램을 시작할 수 있습니다.

이 단계는 아래 그림 5.4.2에 표시된 항목을 제외하고 작업 5.3.2와 동일합니다.

  1. 이 단계가 수행하는 작업을 설명하는 단계 이름입니다.
  2. PowerShell.exe에 대한 절대 경로 및 EPM 앱 노드에 host_switch_failover.ps1 스크립트를 설치한 위치에 붙여넣습니다.
  3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

plan-custom-so-newport-grp2-step1.png
그림 5.4.2: 호스트 파일을 업데이트하는 매개변수

태스크 5.4.3: EPM System 서비스 시작 스크립트에 대한 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 EPM 시스템 서비스는 지역 2에서 시작됩니다.

  1. 이 단계가 수행하는 작업을 설명하는 단계 이름입니다.
  2. PowerShell.exe에 대한 절대 경로 및 EPM 앱 노드에 start_services.ps1 스크립트를 설치한 위치에 붙여넣습니다.
  3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.
  4. 이제 두 개의 사용자정의 스크립트를 실행하는 두 단계가 포함된 계획 그룹을 추가하려면 추가를 누릅니다.

plan-custom-so-newport-grp2-step2.png
그림 5.4.3: EPM을 시작할 매개변수

이제 다음 스크린샷에 표시된 대로 전환 계획에 DR 계획 그룹이 모두 포함되어야 합니다.

plan-custom-so-newport-all-grps.png
그림 5.4.4: 시작 후 사용자 정의 스크립트

작업 6: 영역 2의 페일오버 계획 사용자 정의(새 포트)

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

작업 6.1: 복구 계획 선택

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

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

plan-custom-fo-newport-nav.png
그림 6-1: 영역 2의 페일오버 계획 사용자 정의를 시작하는 방법

작업 6.1.2: 새 사용자 정의 계획 그룹에 단계 추가

  1. 그룹 추가를 누릅니다.

    plan-custom-fo-newport-grp1-step.png
    그림 6.1.2 EPM을 시작하기 위한 계획 단계를 생성하는 매개변수

  2. 작업 5.4의 지침에 따라 사용자 정의 계획 그룹에 두 단계를 추가하여 사용자 정의 스크립트 host_switch_failover.ps1 및 start_services.ps1를 실행합니다.

  3. 단계 및 유저 정의 계획 그룹을 추가한 후에는 Failover 계획이 다음과 같아야 합니다.

    plan-custom-fo-newport-grp1-finish.png
    그림 6.1.3 EPM을 시작하고 호스트를 업데이트하기 위한 계획 단계를 생성하는 매개변수

작업 7: 영역 2(Newport)에서 Switchover 계획 실행

스위치오버 및 페일오버 DR 계획은 모두 대기 영역 2(Newport)에서 완료되었습니다. 리전 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(뉴포트)로 전환합니다.

작업 7.1: 계획 실행 시작

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

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

이미지-exec-so-to-newport-begin.png
그림 7-1: 대기 영역으로 스위치오버를 실행하는 방법 표시

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

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

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

이미지-exec-so-to-newport-exec.png
그림 7.2: 전환 계획을 선택하고 실행합니다.

작업 7.3: 다음 단계

EPM System 워크로드가 지역 1에서 지역 2로 완전히 전환될 때까지 스위치오버 계획을 모니터링합니다. 전체 스택 DR은 아티팩트를 정리하고 영역 간에 기본 및 대기 롤을 변경합니다. switchover 계획 실행이 실패할 경우 로그를 확인하고 계획이 성공적으로 실행되었는지 확인합니다.

Full Stack DR이 스위치오버를 완료하면 영역 2(Newport)가 기본 영역이 되고 영역 1(런던)이 대기 영역이 됩니다.

작업 8: 영역 1(런던)에서 DR 계획 생성

이제 대기 피어인 영역 1(런던)에 대해 DR 보호 그룹에서 동일한 기본 전환 및 페일오버 계획을 생성합니다.

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

OCI Full Stack DR은 이전 작업에서 추가된 멤버 리소스를 기반으로 두 계획을 기본 제공 단계로 미리 채웁니다. 이후 단계에서는 복구 작업 중 EPM System과 관련된 모든 태스크를 처리하도록 계획을 사용자 정의합니다.

switchover 계획은 항상 standby 롤을 사용하여 보호 그룹에 생성됩니다. 영역 1은 현재 작업 8에서 switchover 계획을 실행한 후에 standby 보호 그룹입니다.

작업 8.1: DR 계획 생성

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

  1. OCI 지역 컨텍스트가 지역 1(런던)인지 확인합니다.
  2. 영역 1에서 대기 DRPG를 선택합니다.
  3. 플랜을 선택합니다.
  4. 계획 생성을 눌러 프로세스를 시작합니다.
  5. switchover 계획의 이름을 단순하지만 의미 있게 만듭니다. 이름은 가능한 한 짧아야하지만 위기 동안 혼란과 인간의 실수를 줄이는 데 도움이되는 한 눈에 이해하기 쉽습니다.
  6. 계획 유형을 전환(계획)으로 선택합니다. 이 글을 쓸 때에는 네 가지 계획 유형만 있습니다.
  7. 기본 내장 단계로 미리 채워진 기본 전환 계획을 생성하려면 생성을 누릅니다.

plan-create-lon-so.png
그림 8.1: DR 전환 계획을 생성하는 데 필요한 매개변수

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

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

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

  2. 계획 유형을 페일오버(계획되지 않음)로 선택합니다. 이 글을 쓸 때 네 가지 계획 유형이 있습니다.

  3. 기본 내장 단계로 미리 채워진 기본 복구 계획을 생성하려면 생성을 누릅니다.

plan-create-lon-fo.png
그림 8.2: DR 복구 계획을 생성하는 데 필요한 매개변수입니다.

이제 영역 1의 대기 DR 보호 그룹에는 아래와 같이 두 개의 DR 계획이 있어야 합니다. 이들은 리전 2에서 리전 1로 워크로드를 전환하는 작업을 처리합니다.

plan-create-lon-completed.png
그림 8.3: 더 이상 진행하기 전에 영역 2에 존재해야 하는 두 가지 기본 DR 계획 표시

작업 9: 영역 1(런던)에서 Switchover Plan 커스터마이즈

이 작업에 대한 모든 작업은 영역 1에서 수행된다는 점을 제외하고 영역 2에 대한 작업 5에서 수행한 것과 거의 동일합니다.

작업 8에서 생성된 기본 DR 계획에는 OCI Full Stack DR에 내장되어 있으며 EPM System 애플리케이션과 관련된 복구 작업을 관리할 수 있는 단계가 포함되어 있지 않은 복구 작업에 대한 미리 채워진 단계가 포함되어 있습니다. 이 단계에서는 사용자 정의 DR 계획 그룹 및 EPM System에 대한 전환 중 수행해야 하는 태스크를 관리하는 단계를 추가하는 방법에 대해 설명합니다.

작업 9.1: 전환 계획 선택

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

플랜-custom-so-lon-nav.png
그림 9-1: 영역 1에서 switchover 계획을 커스터마이즈하는 방법

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

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

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

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

OCI Full Stack DR이 프로덕션으로 전환되면 해당 계획 그룹을 활성화해야 합니다. 스위치오버 및 스위치백을 테스트하는 동안 이러한 두 계획 그룹이 사용 안함으로 설정된 동안 제자리에 남아 있던 모든 아티팩트는 운용 단계로 이동하기 전에 종료하고 정리하여 정상적인 작동 중 혼동 및 인적 오류 가능성을 줄여야 합니다.

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

plan-custom-so-lon-disabled-show.png
그림 9-2: 기본적으로 사용 안함으로 설정된 계획 그룹

다음은 사용 안함으로 설정된 계획 그룹이 사용으로 설정될 때 수행하는 작업입니다.

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

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

태스크 9.2.1: 컴퓨트 계획 종료 그룹 사용

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

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

    plan-custom-so-newport-enable-terminate-vm.png
    그림 9.2.1: 컴퓨트 인스턴스 종료를 사용으로 설정하는 방법

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

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

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

    plan-custom-so-newport-enable-terminate-vg.png
    그림 9.2.2: 종료 볼륨 그룹을 사용으로 설정하는 방법

태스크 9.3: 영역 2(기본)에서 사용자정의 스크립트를 실행하는 계획 그룹 생성

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

첫 번째 사용자 정의 계획 그룹은 사용자정의 스크립트를 실행하여 기본 영역 2에서 실행되는 EPM System 서비스를 중지합니다. 이 계획 그룹에는 작업 1.2의 DR 제어 노드에 있는 c:/scripts 폴더로 다운로드된 Windows PowerShell 스크립트 stop_services.ps1를 호출하는 단일 단계가 포함됩니다.

태스크 9.3.1: 계획 그룹 추가 선택

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

  1. 시작하려면 그룹 추가를 누르십시오.
  2. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
  3. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 영역 2에서 VM을 중지하는 기본 제공 계획 그룹 앞에 사용자 정의 계획 그룹을 삽입합니다.
  4. 기본 제공 계산 인스턴스 정지(기본) 계획 그룹을 선택합니다.
  5. 단계 추가를 눌러 EPM System을 정지할 스크립트를 지정할 대화상자를 엽니다.

플랜-custom-so-lon-grp1-name.svg
그림 9.3.1: 계획 그룹을 생성하고 EPM System 서비스를 정지하기 위한 단계를 추가하는 매개변수

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

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 지역 2의 EPM System 서비스가 중지됩니다.

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

  1. 이 단계가 수행하는 작업을 설명하는 단계 이름입니다.
  2. 스크립트가 EPM Services를 중지하지 못하면 DR 계획이 중지되어야 합니다. 그러면 누구나 문제가 있음을 확인하고 해결할 수 있습니다. Full Stack DR은 문제를 해결한 후 스위치오버 계획을 계속 실행할 수 있는 기회를 제공합니다.
  3. OCI Full Stack DR이 장애를 선언하기 전의 기본값은 1시간입니다. 이 값은 30분으로 변경하거나 보다 사실적인 시간 초과 값으로 느껴지는 값을 변경할 수 있습니다.
  4. DR 제어 노드가 현재 실행 중인 영역을 스위치오버 중 실행될 위치가 아닌 항상 선택합니다. OCI Full Stack DR은 VM이 실행되는 위치를 추적하므로 현재 위치를 지정하기만 하면 됩니다. 이 경우 DR 제어 노드는 영역 1(런던)에서 실행 중입니다.
  5. 로컬 스크립트 실행을 선택하여 컴퓨트 인스턴스에서 스크립트를 찾을 수 있음을 Full Stack DR에 알립니다. Windows PowerShell 스크립트가 작업 1.2의 DR 제어 노드로 다운로드되었습니다.
  6. DR 제어 노드를 포함하는 올바른 컴파트먼트를 선택합니다. 그런 다음 DR 제어 노드로 지정된 컴퓨트 인스턴스를 선택합니다. 이 예에서는 EPM System 애플리케이션 컴퓨트입니다.
  7. DR 제어 노드에 stop_services.ps1 스크립트를 설치한 절대 경로를 붙여 넣습니다. 첫번째 파라미터로 stop을 추가하고 OCI 지역 ID를 두번째 파라미터로 추가합니다.
  8. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

플랜-custom-so-lon-grp1-step1.svg
그림 9.3.2: 계획 그룹을 생성하고 단계를 추가하여 EPM System 서비스를 시작하는 매개변수

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

  1. 이제 그림 9.3.3과 같이 EPM System 중지 단계가 DR 계획 그룹에 추가됩니다.

    플랜-custom-so-lon-grp1-step1-added.svg
    그림 9.3.3: 계획 그룹을 생성하고 EPM 시스템 서비스 중지에 단계를 추가하는 매개변수

  2. 방금 추가된 계획 단계가 표시됩니다. DR 계획 그룹에 단계를 더 추가할 수 있지만 이 계획 그룹에는 EPM 서비스를 중지하는 단계만 포함됩니다.

  3. 추가를 눌러 DR 계획 그룹 및 단계를 DR 계획에 추가합니다.

    플랜-custom-so-lon-grp1-added.svg
    그림 9.3.4: EPM 시스템 서비스 중지에 추가된 계획 그룹 및 그룹을 생성하는 매개변수

작업 9.4: 영역 1(대기)에서 사용자 정의 스크립트를 실행할 계획 그룹 생성

두 번째 사용자 정의 계획 그룹은 대기 영역 1에서 DR 제어 노드가 실행된 후 컴퓨트 노드의 호스트 파일을 업데이트하고 EPM System 서비스를 시작합니다. 이 계획 그룹에는 작업 1.2의 DR 제어 노드에 다운로드된 host_switch_failback.ps1 및 start_services.ps1 PowerShell 스크립트를 호출하는 두 단계가 포함됩니다. host_switch_failback.ps1 스크립트는 Newport 영역에서 host_switch_failover.ps1 스크립트에 의해 도입된 변경 사항을 되돌리고 원래 기본 영역 London으로 다시 이동된 후 컴퓨트 노드에서 원래 호스트 파일을 복원합니다.

작업 9.4.1 대기 영역으로 전환한 후 호스트 파일을 업데이트할 DR 계획 그룹 생성

  1. 계획 그룹에 단순하지만 설명적인 이름을 지정합니다.
  2. 계획 그룹이 DR 계획에 삽입될 위치를 선택합니다. 이 경우 영역 1에서 DR 제어 노드의 기능도 수행하는 EPM System 애플리케이션 노드의 복제된 버전을 실행하는 기본 제공 계획 그룹 뒤에 사용자 정의 계획 그룹을 삽입합니다.
  3. 내장 컴퓨트 인스턴스 실행(대기) 계획 그룹을 선택합니다.
  4. 호스트 파일을 업데이트할 스크립트를 지정할 대화상자를 열려면 단계 추가를 누릅니다.

계획-사용자 정의-soo-lon-grp1-step1.svg
그림 9.4.1: 호스트 파일 업데이트를 위해 추가된 계획 그룹 및 그룹을 생성하는 매개변수

작업 9.4.2: 호스트 파일 업데이트 스크립트에 대한 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. host_switch_failback.ps1 스크립트는 컴퓨트 노드의 호스트 파일을 업데이트합니다. Newport 영역에서 host_switch_failback.ps1 스크립트에 의해 도입된 변경 사항을 되돌리고 영역 1(런던)에 대한 원래 호스트 파일을 복원합니다. 이렇게 하면 응용 프로그램 계층에서 추가 수정 없이 응용 프로그램을 시작할 수 있습니다.

이 단계는 그림에 표시된 항목을 제외하고 작업 9.3.2와 동일합니다.

  1. 이 단계가 수행하는 작업을 설명하는 설명적인 이름입니다.
  2. PowerShell.exe에 대한 절대 경로 및 DR 제어 노드에 host_switch_failover.ps1 스크립트를 설치한 위치에 붙여 넣습니다.
  3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.

플랜-custom-so-lon-grp1-step1-details.svg
그림 9.4.2: 호스트 파일 업데이트를 위해 추가된 계획 그룹 및 단계 세부 정보를 생성하는 매개변수

태스크 9.4.3: EPM System 서비스 시작 스크립트에 대한 단계 이름 및 로컬 스크립트 매개변수 제공

계획 그룹 추가 단계 대화상자에서는 이 한 단계가 수행할 작업과 복구 중 동작 방식에 대한 매개변수를 지정할 수 있습니다. 이 경우 EPM 시스템 서비스는 지역 2에서 시작됩니다.

  1. 이 단계가 수행하는 작업을 설명하는 설명적인 이름입니다.
  2. PowerShell.exe에 대한 절대 경로 및 DR 제어 노드에 start_services.ps1 스크립트를 설치한 위치에 붙여 넣습니다.
  3. 단계 추가를 눌러 이 단계를 계획 그룹에 추가합니다.
  4. 이제 두 개의 사용자정의 스크립트를 실행하는 두 단계가 포함된 계획 그룹을 추가하려면 추가를 누릅니다.

이제 다음 스크린샷에 표시된 대로 전환 계획에 DR 계획 그룹이 모두 포함되어야 합니다.

플랜-custom-so-lon-all-grps.png
그림 9.4.3: 사용자 정의 계획 그룹 전환

작업 10: 영역 1(런던)에서 Failover 계획 사용자 정의

이 태스크는 영역 2에 대한 실제 운용중단 또는 액세스 손실 중 영역 1의 EPM System 페일오버 중 수행해야 하는 태스크를 관리하기 위해 사용자정의 사용자 정의 DR 계획 그룹 및 단계를 추가하는 방법에 대해 설명합니다. 위 작업 9의 스위치오버 계획에 방금 추가된 동일한 단계의 하위 세트가 됩니다. 그러나 대기 영역 1에서 실행되는 단계만 복구 계획에 추가됩니다. 페일오버 중에 영역 2에 완전히 액세스할 수 없다고 가정하기 때문입니다.

태스크 10.1: 페일오버 계획에 사용자 정의 계획 그룹 추가

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

plan-create-lon-failover.png
그림 10.1: 영역 1의 복구 계획

작업 10.1.1: 계획 그룹 추가

  1. 대기 영역 2가 여전히 콘솔의 현재 영역 컨텍스트인지 확인하십시오.
  2. 페일오버 계획을 선택합니다.
  3. 그룹 추가를 누릅니다.
  4. 그룹 이름을 지정합니다.
  5. 컴퓨트 인스턴스 실행 단계에서 내장된 후 계획에 추가합니다.

plan-custom-fo-lon-add-grp.png
그림 10.1: 영역 2로 페일오버한 후 사용자 정의 스크립트를 실행하기 위한 계획 그룹을 생성하는 매개변수입니다.

태스크 10.1.2: 새 사용자 정의 계획 그룹에 단계 추가

  1. 작업 9.4의 지침에 따라 사용자 정의 계획 그룹에 두 단계를 추가하여 사용자 정의 스크립트 host_switch_failback.ps1를 실행합니다.

    plan-custom-fo-lon-add-step1.png
    그림 10.2: 호스트 파일을 업데이트하는 스크립트에 대한 계획 그룹 단계를 생성하는 매개변수입니다.

  2. start_services.ps1 스크립트를 사용하여 서비스를 시작하는 두번째 단계를 계획 그룹에 추가합니다.

    plan-custom-fo-lon-add-step1.png
    그림 10.3: 호스트 파일을 업데이트하는 스크립트에 대한 계획 그룹 단계를 생성하는 매개변수입니다.

  3. 단계를 추가한 후 사용자 정의 계획 그룹은 다음과 같아야 하며 추가를 누릅니다.

    plan-custom-fo-lon-added-steps.png
    그림 10.4: 컴퓨트 인스턴스가 실행된 후 두 개의 로컬 스크립트를 실행하도록 구성된 단계를 보여주는 계획 그룹입니다.

  4. 이제 다음 스크린샷에 표시된 대로 페일오버 계획에 EPM System에 대한 사용자 정의 DR 계획 그룹이 포함되어야 합니다. 보호 그룹에 EPM System과 함께 다른 애플리케이션 또는 OCI 서비스가 포함된 경우 추가 계획 그룹이 있을 수 있습니다.

    plan-custom-fo-lon-all-groups.png
    그림 10.5: 사용자 정의 계획 그룹을 보여주는 페일오버 계획

다음 단계

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

Switchover 계획 테스트

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

Failover 계획 테스트

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

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

복구 팀은 OCI Full Stack DR 보호 그룹의 준비 상태 및 운영 워크로드 계획을 입증하기 위한 최종 검증을 수행해야 합니다. 이 과정에서 지역 2(Newport)는 주요 지역이어야 합니다. 다음 단계를 완료하여 모든 계획의 최종 검증을 시작합니다.

확인

추가 학습 자원

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

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