수명 주기 작업

보조 사이트가 기본 사이트와 동기화된 상태로 유지하려면 정기적인 라이프사이클 유지 관리가 필요합니다. 수명 주기 동안 계획된 스위치오버를 수행하여 기본 및 보조 사이트의 역할을 전환하고 예상치 않은 작업 또는 계획되지 않은 작업에 응답할 수 있습니다.

구성 복제 정보

파일 시스템에 있는 컨텐츠의 초기 복제는 DR 설정 중 수행되었습니다. 보조 사이트를 기본 사이트로 최신 상태로 유지하려면 정기적으로 파일 시스템 복제를 반복해야 합니다.

DR 설정 중 생성한 것과 동일한 스크립트를 사용하고, 파일 시스템 아티팩트를 OCI에 복제하고, 파일 시스템 복제본을 각 아티팩트에 대해 다음 고려 사항으로 스케줄링할 수 있습니다.

• 수명 주기 동안 Oracle 홈 복제

  정적 아티팩트입니다. 자주 변경되지 않으므로 정기적으로 복제할 필요가 없습니다. Oracle 홈(예: 패치 작업)에서 수정을 수행할 때만 복제해야 합니다.

• 수명 주기 동안 WebLogic 도메인 공유 구성 복제

  동적 아티팩트입니다. 특히 SOA 도메인 구성의 소스인 ASERVER_HOME와 응용 프로그램이 배치, 배치 해제, 업데이트될 때마다 업데이트되는 APPLICATION_HOME가 포함됩니다.

  이 WebLogic 도메인 공유 구성은 자주 변경될 것으로 예상됩니다. 시스템에서 구성 변경사항이 발생하는 빈도에 따라 더 많거나 덜 빈번하게 이 아티팩트의 정기 복제를 스케줄링합니다. 기본에 대한 구성 변경을 수행할 때마다 복제를 수행하는 방법도 제어됩니다.

• 수명 주기 동안 WebLogic 도메인 전용 구성 복제

  또한 동적 아티팩트로, MSERVER_HOME 및 NM_HOME를 포함합니다. 초기 설정 후에는 nodemanager 홈에 빈번한 업데이트가 있을 것으로 예상되지 않습니다. MSERVER_HOME의 내용은 관리 서버에서 사용하는 도메인 폴더를 포함하므로 ASERVER_HOME만큼 자주 변경됩니다. 하지만 관리 서버가 시작되고 WebLogic 스크립팅 툴(WLST) 또는 Oracle WebLogic Server 관리 콘솔을 사용하여 구성 변경 사항이 적용되는 경우 대부분의 콘텐츠(ASERVER_HOME/config)가 AdminServer에서 새로 고쳐지고 다운로드됩니다. 이 아티팩트를 공유 구성만큼 자주 복제하는 것은 중요하지 않습니다. MSERVER_HOME의 다른 폴더에 대한 수정(예: MSERVER_HOME/bin 폴더의 수정)이 수행된 경우에만 이를 복제해야 합니다.

• 공유 런타임 폴더 복제

  이 폴더에 런타임 아티팩트를 저장하는 경우 비즈니스 요구에 따라 복제본을 대기로 스케줄링합니다.

  Oracle Cloud Infrastructure File Storage 파일 시스템을 사용하고 rsync를 사용하여 복제하는 대신 공유 런타임 콘텐츠에 DBFS(Oracle Database File System) 마운트를 사용할 수 있습니다. 이렇게 하면 컨텐트가 데이터베이스에 상주하고 기본 Oracle Data Guard 복제본을 사용하여 보조 데이터베이스에 자동으로 복제됩니다. DBFS 사용에 대한 자세한 내용은 Learn More의 About Oracle Database File System를 참조하십시오.

다음 표는 수명 주기 동안 파일 시스템 아티팩트 복제에 대한 권장 사항을 요약한 것입니다.

아티팩트	포함	권장 사항
Oracle 홈	FMW 홈, JDK, 재고	필요 시에만 복제(예: 패치 후)
WebLogic 도메인 공유 구성	ASERVER_HOME, applications, deployment plans, keys Keystore	복제 일정을 잡습니다. 높은 빈도가 필요할 수 있습니다. 빈도는 SOA 시스템에 구성 변경이 수행되는 빈도에 따라 달라집니다.
WebLogic 도메인 개인 구성	MSERVER_HOMES, nodemanager config	복제 일정을 잡습니다. 높은 빈도는 일반적으로 필요하지 않습니다.
공유 런타임	고객별 런타임 아티팩트(JMS 아님, TLOGS 아님)	요구 사항에 따라 결정됩니다. DBFS 마운트인 경우 Oracle Data Guard에서 콘텐츠를 자동으로 복제합니다.

Switchover 수행

전환은 관리자가 두 사이트의 롤을 되돌리는 계획된 작업입니다. 스위치오버 후에 기본 시스템은 보조 시스템이 되고 보조 시스템은 기본 시스템이 됩니다. switchover를 수행하면 기본 사이트에서 작동 중지 시간이 발생합니다.

SOA 하이브리드 DR 구성에서 스위치오버를 수행하기 전에 보류 중인 구성 변경 사항을 전파합니다. 보류 중인 보조 사이트에 복제된 변경사항이 없는지 확인합니다.

1. switchover가 수행되는 동안 예약된 복제를 사용 안함으로 설정하면 작업이 실패하고 스위치오버 작업 자체를 방해할 수 있습니다.
2. 기본 사이트에서 Oracle HTTP Server 시스템을 정지합니다.
3. 기본 사이트에서 서버를 중지합니다.
   WebLogic 관리 서버 콘솔 또는 스크립트를 사용하여 기본 사이트의 WebLogic 서버를 중지합니다.

   참고:

   기본 사이트의 관리 서버는 스위치오버 중에 계속 작동할 수 있습니다. 하지만 사이트가 대기 롤일 때 중지하는 것이 좋습니다. 대기 사이트의 도메인 구성이 수명 주기 동안 기본 구성으로 무효화될 것으로 예상되기 때문입니다. 이 경우 관리 서버가 작동 중인 경우 사용되지 않는 구성으로 실행됩니다.
4. 프론트 엔드 DNS 이름을 스위치오버합니다.

   시스템에서 사용하는 이름을 호스트하는 DNS 서버에서 필요한 DNS 푸시를 수행하거나 클라이언트의 파일 호스트 확인을 변경하여 시스템의 프론트 엔드 가상 이름을 보조 사이트의 로드 밸런서가 사용하는 공용 IP로 가리킵니다.

   DNS가 외부 프런트엔드 분석(예: OCI DNS 또는 상용 DNS)에 사용되는 시나리오의 경우 API를 사용하여 변경 사항을 푸시할 수 있습니다. OCI DNS에서 이 변경사항을 푸시하는 예를 보려면 GitHub(예: 스크립트)로 이동하십시오.

   DNS 항목의 TTL 값은 스위치오버의 RTO에 영향을 미칩니다. TTL이 높을 경우(예: 20분) DNS 변경사항은 클라이언트에서 해당 시간을 적용합니다. TTL 값을 낮추면 이 속도는 빨라지지만 클라이언트가 캐시된 이름을 사용하는 대신 DNS에 더 자주 도달하기 때문에 오버헤드가 발생할 수 있습니다. 좋은 방법은 DNS를 변경하기 전에 TTL을 일시적으로 낮은 값(예: 1분)으로 설정하는 것입니다. 그런 다음 변경 작업을 수행하고 스위치오버 절차가 완료되면 TTL을 원래 값으로 다시 되돌립니다.

5. oracle 사용자로 기본 데이터베이스 호스트에서 Oracle Data Guard 브로커를 사용하여 데이터베이스 전환을 수행합니다.
   기본 데이터베이스의 고유한 이름과 시스템 비밀번호가 필요합니다.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> switchover to secondary_db_unqname

6. 아직 작동 중이지 않은 경우 보조 사이트(새 기본 사이트)에서 Oracle HTTP Server 시스템을 시작합니다.
7. 보조 사이트(새 기본 서버)에서 관리 서버를 시작하거나 서버가 이미 시작된 경우 서버를 다시 시작합니다.
   관리 서버를 시작하면 대기 상태였던 동안 복제된 구성 변경 사항이 적용됩니다.
8. 보조 사이트(새로운 기본 서버)에서 보조 관리 서버를 시작합니다.
   WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.

페일오버 수행

페일오버 작업은 일반적으로 기본 사이트를 사용할 수 없게 될 때 수행되는 계획되지 않은 작업입니다. 원래 기본 데이터베이스가 실패하고 해당 데이터베이스를 적절한 시기에 복구할 가능성이 없으면 대기 데이터베이스를 기본 데이터베이스 롤로 변환할 수 있습니다. 기본 데이터베이스 실패 시 기본 및 대상 대기 데이터베이스가 일관성이 있는지 여부에 따라 데이터 손실이 발생할 수 있습니다.

1. 가능한 경우 보류 중인 구성 변경사항을 전달합니다.
   보조 사이트에 대한 변경사항을 복제하려면 파일 시스템 아티팩트를 OCI에 복제를 참조하십시오.
2. switchover가 수행되는 동안 예약된 복제를 사용 안함으로 설정하면 작업이 실패하고 스위치오버 작업 자체를 방해할 수 있습니다.
3. 기본 사이트에서 Oracle HTTP Server 시스템을 정지합니다.
4. 가능한 경우 기본 사이트에서 관리 서버를 중지합니다.

   WebLogic 관리 서버 콘솔 또는 스크립트를 사용하여 기본적으로 관리되는 서버를 중지합니다.

5. 프론트 엔드 DNS 이름을 스위치오버합니다.

   시스템에서 사용하는 이름을 호스트하는 DNS 서버에서 필요한 DNS 푸시를 수행하거나 클라이언트의 파일 호스트 확인을 변경하여 시스템의 프론트 엔드 가상 이름을 보조 사이트의 로드 밸런서가 사용하는 공용 IP로 가리킵니다.

   DNS가 외부 프런트엔드 분석(OCI DNS, 상용 DNS 등)에 사용되는 시나리오의 경우 적절한 API를 사용하여 변경 사항을 푸시합니다. OCI DNS에서 이러한 변경 사항을 푸시하는 예를 보려면 여기로 이동하십시오.

   참고:

   DNS 항목의 TTL 값은 스위치오버의 RTO에 영향을 미칩니다. TTL이 높을 경우(예: 20분) DNS 변경은 클라이언트에서 해당 시간을 소비합니다. TTL 값을 낮추면 이 속도는 빨라지지만 클라이언트가 캐시된 이름을 사용하는 대신 DNS에 더 자주 도달하기 때문에 오버헤드가 발생할 수 있습니다. 좋은 방법은 DNS를 변경하기 전에 TTL을 일시적으로 낮은 값(예: 1분)으로 설정하는 것입니다. 그런 다음 변경 작업을 수행하고 스위치오버 절차가 완료되면 TTL을 원래 값으로 되돌립니다.
6. oracle 유저로 secondary 데이터베이스 호스트의 Oracle Data Guard broker를 사용하여 복구를 수행합니다.
   기본 데이터베이스의 고유한 이름과 시스템 비밀번호가 필요합니다.

   [oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
   DGMGRL> failover to secondary_db_unqname

7. 아직 작동 중이지 않은 경우 보조 사이트(새 기본 사이트)에서 Oracle HTTP Server 시스템을 시작합니다.
8. 보조 사이트(새 기본 서버)에서 관리 서버를 시작하거나 서버가 이미 시작된 경우 서버를 다시 시작합니다.
   관리 서버를 시작하면 대기 상태였던 동안 복제된 구성 변경 사항이 적용됩니다.
9. 보조 사이트(새로운 기본 서버)에서 보조 관리 서버를 시작합니다.
   WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.

검증을 위해 2차 항목 열기

standby database를 snapshot standby로 변환하여 complete switchover를 수행하지 않고 standby 사이트를 검증할 수 있습니다. 이렇게 하면 보조 SOA 서버를 대기 사이트에서 시작하고 보조 시스템을 확인할 수 있습니다. {\f2732 snapshot standby }모드일 때{\f2732 standby }사이트 데이터베이스에서 수행된 모든 변경 사항은 물리적{\f2732 standby database}로 다시 변환되면 폐기됩니다{\f2732 .} 기본 데이터가 보조 사이트 검증의 영향을 받지 않습니다.

참고:

이 작업은 주의해서 수행해야 합니다. 스냅샷으로 변환될 때 데이터베이스에 보류 중인 메시지나 조합이 있을 경우 대기 사이트의 SOA 서버가 시작될 때 이를 처리합니다. 스냅샷 대기로 변환할 때 기본 데이터베이스에 보류 중인 작업이 없는지 확인하십시오. 그렇지 않으면 스냅샷 대기 데이터베이스로 변환된 후 보조 사이트의 SOA 서버를 시작하기 전에 대기 데이터베이스의 런타임 SOA 테이블에서 레코드를 제거합니다. 전환을 수행하지 않고 대기 사이트를 검증하는 단계는 테이블을 삭제하지 않고 런타임 테이블에서 레코드 제거를 참조하십시오.

1. oracle 사용자로 기본 db 호스트에서 Oracle Data Guard 브로커를 사용하고 보조를 스냅샷 대기로 변환합니다.

   [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
   DGMGRL> convert database secondary_db_unqname to snapshot standby
   

   show configuration 명령을 사용하여 변환이 올바르게 수행되었는지 확인합니다.
2. 보조 환경에 보류 중인 작업이 없는지 확인합니다.
   대기가 스냅샷으로 변환될 때 기본 DB에 보류 중인 작업(트랜잭션, 메시지)이 있을 경우 보조 SOA 서버는 start.You가 SOA 잘라내기 스크립트를 사용하여 보조 서버의 SOA 런타임 테이블에서 레코드를 제거하여 보조 서버를 시작하기 전에 런타임 데이터를 정리할 수 있을 때 해당 작업을 처리하려고 시도합니다. 이 작업은 주 데이터베이스에서 테이블을 잘라내지 않도록 주의하여 실행하십시오. 테이블을 삭제하지 않고 런타임 테이블에서 레코드 제거를 참조하십시오.
3. 아직 작동 중이지 않은 경우 보조 사이트에서 Oracle HTTP Server 시스템을 시작합니다.
4. 보조 사이트에서 관리 서버를 시작합니다.
5. 보조 사이트에서 보조 관리 서버를 시작합니다.
   WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.
6. 보조 사이트를 검증합니다.

   이 이름은 스위치오버가 아니며 기본 사이트가 여전히 활성 상태이므로, 가상 프론트 엔드 이름은 기본 사이트의 로드 밸런서 IP 주소로 확인되므로 모든 브라우저 액세스는 기본적으로 활성 기본 사이트로 재지정됩니다.

   보조 사이트의 SOA 서비스에 직접 액세스하려면 제어된 클라이언트(예: 랩탑)에서 /etc/hosts 파일을 업데이트하고, 보조 사이트의 프론트 엔드 로드 밸런서 IP 주소로 분석하도록 가상 프론트 엔드 이름을 설정하고, 이 클라이언트에서 검증을 실행해야 합니다.

   참고:

   HTTP 프록시가 클라이언트의 /etc/hosts에 있는 이름에 관계없이 기본 사이트의 로드 밸런서 IP 주소로 가상 프론트 엔드 이름을 계속 확인할 수 있으므로 검증에 사용된 클라이언트가 HTTP 프록시를 통해 시스템에 액세스하지 않는지 확인합니다.

   비Linux 클라이언트의 경우 브라우저가 사용자 정의된 호스트 파일 항목을 사용하여 IP 주소를 분석하기 전에 로컬 DNS 캐시를 재설정해야 할 수 있습니다.

   보조 사이트가 검증되면 다음 단계로 이동하여 대기 역할로 되돌립니다.

   참고:

   보조 사이트를 검증하는 데 시간이 걸릴 수 있습니다.
7. 보조 사이트에서 관리 서버와 관리 서버를 중지합니다.
   보조 WebLogic 콘솔을 사용하여 보조 사이트에서 관리 서버 및 관리 서버를 종료합니다.
8. oracle 사용자로 primary 데이터베이스 호스트에서 Oracle Data Guard 브로커를 사용하고 보조를 물리적 대기로 다시 변환합니다.
   기본 데이터베이스의 고유한 이름과 시스템 비밀번호가 필요합니다.

   [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
       DGMGRL> convert database secondary_db_unqname to physical standby

   변환을 확인하려면 show configuration을 사용합니다.
9. 업데이트된 /etc/hosts 파일을 되돌립니다.
   검증을 위해 보조 사이트를 가리키도록 클라이언트의 /etc/hosts 파일을 업데이트한 경우 가상 프론트 엔드 이름이 기본 프론트 엔드 IP 주소를 다시 가리키도록 되돌립니다.

참고:

ORA-01403: 데이터를 찾을 수 없음 ORA-06512 오류

여기서 설명한 대로 보조 사이트를 검증하는 동안(전체 스위치오버를 수행하지 않고, 즉 스냅샷 대기 모드로 대기를 여는 것) "ORA-01403: 발견된 데이터가 없음 ORA-06512" 오류가 대기 SOA 서버의 로그에 표시될 수 있습니다. 이러한 오류는 SOA 자동 비우기 작업과 관련이 있습니다. 이 오류는 데이터베이스의 작업에 db 롤 종속성이 있을 수 있기 때문에 발생합니다. 이 오류는 데이터베이스가 기본 롤에 있는 경우에만 활성화되도록 정의됩니다. 이는 작업이 두 번(기본 및 대기 데이터베이스에서 한 번) 실행되지 않도록 방지하는 예상 동작입니다. SOA 자동 비우기 작업은 기본 역할로 정의되므로 데이터베이스가 스냅샷 대기 모드에 있을 때 DBA_SCHEDULER_JOBS 뷰에 표시되지 않습니다. 각 작업에 대해 정의된 database_role는 DBA_SCHEDULER_JOB_ROLE 뷰에서 볼 수 있습니다. 요약하자면 이러한 오류는 대기 시스템에 나타나는 한 무시해도 됩니다. SOA 자동 비우기의 스케줄러 작업은 인스턴스가 롤을 PRIMARY로 변경하는 경우에만 데이터베이스에서 실행됩니다.

OCI에서 관리 서버의 로컬 페일오버

Administration Server가 원래 실행 중인 호스트에 오류가 있을 경우 동일한 사이트의 다른 노드에서 Administration Server를 시작할 수 있습니다. 시스템을 다른 사이트로 완전히 스위치오버할 필요는 없습니다.

참고:

이 수명 주기 작업은 WebLogic 관리 서버가 로컬 고가용성을 위해 VIP를 사용하고 관리 서버 구성 폴더(ASERVER_HOME)가 공유 위치에 있는 경우에만 적용할 수 있습니다.

이 작업을 수행하는 절차는 Verifying Manual Failover of the Administration Server에서 설명합니다. 이렇게 하면 관리 서버에 대한 로컬 페일오버 보호가 제공됩니다. 자동 서비스 이전 기능을 기반으로 하는 로컬 고가용성 보호 기능이 있는 관리 서버에 대해서는 이 작업이 필요하지 않습니다.

기본 서버가 OCI 사이트에서 실행 중일 때 관리 서버를 다른 호스트로 페일오버해야 하는 경우 해당 절차를 수행할 수 있습니다. 그러나 "ADMINVHN 가상 IP 주소를 두번째 호스트로 이전" 단계와 관련하여 추가 작업이 필요합니다.

다음 단계를 수행하여 관리 서버가 실행 중인 SOA 호스트에서 VIP를 분리하고 관리가 이동 중인 SOA 호스트에 연결합니다(SOAHOST1에서 VIP를 분리하고 OCI 사이트의 SOAHOST2에 연결).

1. root 사용자로 SOAHOST1에서 다음 명령을 실행하여 네트워크 인터페이스에서 관리 서버의 VIP를 제거합니다.
   1. 아직 실행 중인 경우 관리 서버를 중지합니다.
   2. VIP가 실행 중인 위치를 확인합니다.

      ip addr show dev ens3

   3. 네트워크 인터페이스에서 IP를 제거합니다.

      ip addr del 100.70.8.120/20 dev ens3

2. SOAHOST1에서 관리 서버의 VIP를 분리합니다.
   1. OCI 콘솔에 연결하고 적합한 지역 및 구획을 선택합니다.
   2. 컴퓨트 인스턴스로 이동합니다. 계산, 인스턴스를 누른 후 SOAHOST1을 누릅니다.
   3. 연결된 VNIC를 누른 다음 관리 서버 VIP가 연결된 VNIC를 선택합니다.
   4. IPv4 Addresses를 누르고 관리 서버에서 사용하는 VIP를 편집합니다.
   5. VIP의 IP 주소와 fqdn 이름을 메모에 저장합니다(예: 100.70.8.120, hydrsoa-VIP.midtiersubnet.hydrvcn.oraclevcn.com).
   6. Delete Private IP를 누릅니다.
3. 관리 서버의 VIP를 SOAHOST2에 연결합니다.
   1. 컴퓨트 인스턴스로 이동합니다. 계산, 인스턴스를 누른 후 SOAHOST2를 누릅니다.
   2. 연결된 VNIC를 누른 다음 관리 서버 VIP가 연결된 VNIC를 선택합니다.
   3. 보조 전용 IP 주소 지정을 누릅니다.
   4. IPv4 주소, 보조 전용 IP 주소 지정을 차례로 누릅니다.
   5. 이전에 사용된 전용(private) IP 주소 및 호스트 이름 값을 입력합니다. 예를 들어, IP는 100.70.8.120이고 호스트 이름은 hydrsoa-vip입니다.
4. 루트 사용자로 SOAHOST2에 로그인한 후 다음 명령을 실행하여 관리 서버의 VIP를 네트워크 인터페이스에 연결합니다.
   1. 네트워크 인터페이스가 실행 중인지 확인합니다.

      ip addr show dev ens3

   2. 네트워크 인터페이스에 Administration Server의 VIP를 추가합니다.

      ip addr add 100.70.8.120/20 dev ens3 label ens3:1

5. Verifying Manual Failover of the Administration Server에 설명된 대로 나머지 단계를 수행합니다.