이 글에서는 Oracle® E-Business Suite(EBS) 애플리케이션을 위한 재해 복구(Disaster Recovery, DR) 시스템의 구축 및 유지 관리 방법을 다룹니다. 특히 테스트 환경에 있는 버전 12.2.5 시스템을 활용해 버전 12.2 애플리케이션용 DR 시스템을 구축하는 일반적인 절차를 소개합니다.
소개
DR 애플리케이션 사이트를 구축하는 절차는 일반적인 클론(clone) 시스템 생성 과정과 매우 유사합니다. 재해가 발생하더라도 XML 파일의 호스트 이름 등 몇 가지 설정만 수정하면 시스템을 즉시 가동할 수 있습니다. PROD 사이트와 DR 사이트 간 동기화를 유지하려면 rsync 같은 동기화 스크립트를 주기적으로 실행해 변경 사항을 DR 사이트에 반영하고, DR 데이터베이스와 DR 사이트의 애플리케이션 노드에도 패치를 함께 적용해야 합니다.
아래에서 설명하는 절차는 물리적 대기(physical standby) 데이터베이스가 이미 기본(primary) 데이터베이스 서버와 연동되어 동기화 상태를 유지하고 있다는 전제로 진행됩니다.
DR 구성 절차
DR 시스템을 구성하기 위한 주요 단계는 다음과 같습니다.
- 아카이빙을 비활성화하고 DR 시스템을 물리적 대기(physical standby) 모드에서 스냅샷 대기(snapshot standby) 모드로 전환합니다.
preclone을 실행해 기본 사이트의 애플리케이션을 DR 사이트로 복사합니다.dualfs옵션으로 node1을 구성합니다.- PROD 사이트와 동일한 구성이 되도록 추가 노드를 등록합니다.
- node1을 시작했다가 종료하며 서비스를 점검합니다.
- 애플리케이션 DR 구성이 완료되면 DR 시스템을 다시 물리적 대기 모드로 되돌립니다.
1. DR 시스템을 스냅샷 대기 모드로 전환
다음 명령을 실행해 로그 적용(log apply)을 중단하고 DR 데이터베이스를 스냅샷 대기 모드로 설정합니다.
$ dgmgrl /
$ edit database "TESTDR" set state=apply-off;
플래시백 데이터베이스 작업을 수행할 수 있도록 플래시백 로깅을 활성화합니다.
SQL> alter system set db_recovery_file_dest_size=1000G scope=both;
SQL> alter system set db_recovery_file_dest='+FRA' scope=both;
SQL> alter system set db_flashback_retention_target=1440 scope=both;
$ Shutdown node2 DR DB
$ sqlplus '/as sysdba'
SQL> shutdown immediate;
DR DB의 node1에서 다음 명령을 실행합니다.
$ sqlplus '/as sysdba'
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database convert to snapshot standby;
SQL> alter database open;
SQL> select name, DB_UNIQUE_NAME, OPEN_MODE, DATABASE_ROLE from v$database;
NAME DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE
--------- ------------------------------ -------------------- ----------------
TESTPRD TESTDR READ ONLY WITH APPLY SNAPSHOT STANDBY
마운트(mount) 모드로 DR DB node2를 다시 시작합니다.
$ sqlplus '/as sysdba'
SQL> startup mount;
2. preclone 실행 및 fnd_nodes 정리
다음 명령으로 fnd_nodes 정보를 정리합니다.
SQL> exec fnd_conc_clone.setup_clean;
SQL> exec ad_zd_fixer.clear_valid_nodes_info;
DR DB 노드에서 auto-config를 node1 → node2 → node1 순서로 실행합니다.
PROD 애플리케이션 티어에서 preclone을 실행한 후, RUN 파일 시스템(FS) node1의 애플리케이션 파일을 DR 애플리케이션 티어 node1의 FS로 복사합니다.
3. dualfs 실행
DR 애플리케이션 티어 node1에서 파일 시스템 경로로 이동한 뒤 다음 명령을 실행합니다.
$ perl adcfgclone.pl appsTier dualfs from <APPL_BASE>/<SID>/apps/<RUN-FS>/EBSapps/comn/clone/bin
아래 프롬프트가 표시되면 adcfgclone이 성공적으로 완료된 것이며, 이때 발생하는 자동 구성(autoconfiguration) 오류는 무시해도 됩니다.
Do you want to startup the Application Services for ……..? (y/n) [n] :
4. PROD 사이트와 동일하게 노드 추가
각 애플리케이션 노드에서 PROD의 env 파일을 대응하는 DR 노드로 복사합니다. 필요에 따라 디렉터리나 파일 이름을 수정한 후 다음 명령을 실행합니다.
$ scp prodnode1:/home/applmgr/prodprd.env /home/applmgr/proddr.env
$ scp prodnode1:/home/applmgr/prodprd_run.env /home/applmgr/proddr_run.env
$ scp prodnode1:/home/applmgr/prodprd_patch.env /home/applmgr/proddr_patch.env
나머지 모든 노드에 대해서도 동일한 작업을 반복합니다.
env 파일을 소싱(source)한 뒤 RUN FS와 PATCH FS에 대해 auto-config를 실행합니다. 예상 결과는 아래와 같습니다.
Configuring OZF_TOP.......COMPLETED
Configuring CSD_TOP.......COMPLETED
Configuring IGC_TOP.......COMPLETED
AutoConfig completed successfully.
Configuring OZF_TOP.......COMPLETED
Configuring CSD_TOP.......COMPLETED
Configuring IGC_TOP.......COMPLETED
AutoConfig completed with errors.
참고: PATCH FS에서 발생하는 오류는 무시해도 됩니다.
5. 테스트
첫 번째 노드를 시작하고 종료하는 방식으로 구성을 테스트합니다.
$ . ./proddr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adstrtal.sh apps/<passwd>
URL 접속과 로그인을 확인한 뒤 애플리케이션을 종료합니다.
$ cd $ADMIN_SCRIPTS_HOME
$ ./adstpall.sh apps/<passwd>
일반 클론 작업과 마찬가지로, PROD 인프라와 동일한 구성을 맞추기 위해 추가 노드를 등록합니다. 대상 node1의 RUN FS와 PATCH FS에서 preclone을 실행한 후 노드를 추가합니다. RUN FS와 PATCH FS의 관리 서버(admin server) 서비스를 시작하고 아래와 같이 preclone을 실행합니다.
$ . ~/testdr.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adpreclone.pl appsTier
$ . ~/testdr_patch.env
$ cd $ADMIN_SCRIPTS_HOME
$ ./adpreclone.pl appsTier
$ cd <RUN_FS_TOP>/EBSapps/comn/clone/bin
$./adclonectx.pl addnode contextfile=<NODE1_RUNFS_CONTEXT.xml> pairsfile=/common_area/applcsf/testprd/pairsfile/mypairsfile.txt
dualfs=yes
node2를 구성하려면 다음 명령을 실행합니다.
$ cd <RUN_FS_TOP>/EBSapps/comn/clone/bin
$ ./adclonectx.pl addnode contextfile=<NODE1_RUNFS_CONTEXT.xml> pairsfile=/common_area/applcsf/testprd/pairsfile/mypairsfile.txt
dualfs=yes
$ perl $FND_TOP/patch/115/bin/txkSetAppsConf.pl \
-contextfile=<RUN-FS-CONTEXT.xml \
-configoption=addMS \
-oacore=testdr2.sherwin.com:<port> \
-oafm=testdr2.sherwin.com:<port> \
-forms=testdr2.sherwin.com:<port> \
-formsc4ws=testdr2.sherwin.com:<port> -- 모든 포트 정보는 컨텍스트 파일에서 확인할 수 있습니다.
같은 방식으로 다른 노드나 외부 티어도 추가해 PROD 시스템과 동일한 구성을 완성합니다.
6. DR 시스템을 물리적 대기 모드로 전환
모든 노드 추가가 완료되면 DR 시스템의 모든 서비스를 종료하고, DR DB를 다시 물리적 대기 모드로 변환한 뒤 Data Guard를 활성화(ON)합니다.
DR DB의 서비스를 종료하고 마운트한 뒤 물리적 대기 모드로 변환하려면 다음 명령을 실행합니다.
SQL> alter database convert to physical standby;
DGMGRL> edit database "TESTDR" set state=apply-on;
동기화 상태를 검증합니다. 다음 예시와 유사한 결과가 나타나야 합니다.
### Transport Lag와 Apply Lag가 다음과 같은지 모니터링합니다:
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
결론
이 글에서는 검증된 DR 사이트를 활용해 EBS 애플리케이션의 재해에 대비하는 방법을 살펴보았습니다. 컨텍스트 파일의 몇 가지 파라미터만 수정하면 시스템을 바로 가동할 수 있으며, 모든 애플리케이션 시스템의 백업을 별도로 유지하고 복원하는 번거로움도 없습니다. PROD 사이트와 DR 사이트 간에 rsync 프로세스를 설정하고, PROD 사이트에 DB 및 AD Online Patching(ADOP) 패치를 적용할 때 DR 사이트에도 동시에 적용하는 것을 권장합니다.
궁금한 점이나 의견이 있다면 피드백 탭을 이용해 주세요.
데이터베이스 서비스에 대해 더 자세히 알아보세요.
Rackspace는 Oracle 제품 분야의 전문 기업으로, Oracle 투자 가치를 극대화할 수 있도록 지원합니다.
Rackspace의 재해 복구 솔루션에 대한 자세한 내용은 백서를 다운로드해 확인하세요.