수명 주기 작업

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

구성 복제 정보

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

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

수명 주기 동안 Oracle 홈 복제
정적 아티팩트입니다. 자주 변경되지 않으므로 정기적으로 복제할 필요가 없습니다. Oracle 홈(예: 패치 작업)에서 수정을 수행할 때만 복제해야 합니다.
수명 주기 동안 WebLogic 도메인 공유 구성 복제
동적 아티팩트입니다. 특히 WebLogic Server 도메인 구성의 소스인 ASERVER_HOME와 응용 프로그램이 배치, 배치 해제, 업데이트될 때마다 업데이트되는 APPLICATION_HOME가 포함됩니다.

이 WebLogic 도메인 공유 구성은 자주 변경될 것으로 예상됩니다. 시스템에서 구성 변경사항이 발생하는 빈도에 따라 더 많거나 덜 빈번하게 이 아티팩트의 정기 복제를 스케줄링합니다. 기본에 대한 구성 변경을 수행할 때마다 복제를 수행하는 방법도 제어됩니다.
수명 주기 동안 WebLogic 도메인 전용 구성 복제
또한 동적 아티팩트이며, MSERVER_HOME 및 NM_HOME를 포함합니다. 초기 설정 후 nodemanager 홈에서 자주 업데이트되지 않을 것으로 예상됩니다. MSERVER_HOME의 콘텐츠는 관리 서버에서 사용하는 도메인 폴더를 포함하므로 ASERVER_HOME만큼 자주 변경됩니다. 하지만 대부분의 콘텐츠(ASERVER_HOME/config)는 관리 서버가 시작될 때와 WLST(WebLogic Scripting Tool) 또는 Oracle WebLogic Server 관리 콘솔을 사용하여 구성 변경사항이 적용될 때 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`, 애플리케이션, 배포 계획, 키 저장소	복제 일정을 잡습니다. 높은 빈도가 필요할 수 있습니다. 빈도는 WebLogic Server 시스템에 구성 변경이 수행되는 빈도에 따라 달라집니다.
WebLogic 도메인 전용 구성	`MSERVER_HOMES`, `nodemanager config`	복제 일정을 잡습니다. 일반적으로 높은 빈도는 필요하지 않습니다.
공유 런타임	고객별 런타임 아티팩트(JMS 아님, TLOGS 아님)	요구 사항에 따라 결정됩니다. DBFS 마운트인 경우 Oracle Data Guard에서 콘텐츠를 자동으로 복제합니다.

Switchover 수행

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

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

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

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

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

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

DNS 항목의 TTL 값은 스위치오버의 RTO에 영향을 줍니다. TTL이 높을 경우(예: 20분), DNS 변경은 클라이언트에서 적용하는 데 시간이 걸립니다. 낮은 TTL 값을 사용하면 속도가 빨라지지만 이로 인해 클라이언트가 캐시된 이름을 사용하는 대신 DNS에 더 자주 도달하므로 오버헤드가 발생할 수 있습니다. 좋은 방법은 DNS가 변경되기 전에 TTL을 일시적으로 낮은 값(예: 1분)으로 설정하는 것입니다. 그런 다음 변경을 수행하고 switchover 프로시저가 완료되면 TTL을 다시 원래 값으로 되돌립니다.
oracle 유저로 primary database 호스트에서 Oracle Data Guard broker를 사용하여 데이터베이스 switchover를 수행합니다.
시스템 비밀번호와 기본 데이터베이스의 고유한 이름이 필요합니다.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
아직 작동 중이지 않은 경우 보조 사이트(새 기본 사이트)에서 Oracle HTTP Server 시스템을 시작합니다.
보조 사이트(새 기본 사이트)에서 관리 서버를 시작하거나 이미 시작된 경우 서버를 재시작합니다.
Admin Server를 시작하면 대기 상태였던 동안 복제된 구성 변경 사항이 적용됩니다.
보조 사이트(새 기본 사이트)에서 보조 관리 서버를 시작합니다.
WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.

Failover 수행

Failover 작업은 일반적으로 기본 사이트를 사용할 수 없을 때 수행되는 계획되지 않은 작업입니다. 원래 기본 데이터베이스가 실패하고 이를 적시에 복구할 가능성이 없으면 대기 데이터베이스를 기본 데이터베이스 롤로 롤 전환할 수 있습니다. {\f2732 primary database failure }시{\f2732 primary database}와{\f2732 target standby database}가 일관적인지 여부에 따라 데이터 손실이 발생할 수 있습니다{\f2732 .}

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

WebLogic 관리 서버 콘솔 또는 스크립트를 사용하여 기본 서버에서 관리되는 서버를 정지할 수 있습니다.
프론트 엔드 DNS 이름을 스위치오버합니다.

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

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

참고:
DNS 항목의 TTL 값이 스위치오버의 RTO에 영향을 줍니다. TTL이 높으면(예: 20분) DNS 변경이 클라이언트에서 효력을 발휘하는 데 시간이 걸립니다. 낮은 TTL 값을 사용하면 이 속도가 빨라지지만 이로 인해 클라이언트가 캐시된 이름을 사용하는 대신 DNS에 더 자주 도달하므로 오버헤드가 발생할 수 있습니다. 좋은 방법은 DNS가 변경되기 전에 TTL을 일시적으로 낮은 값(예: 1분)으로 설정하는 것입니다. 그런 다음 변경을 수행하고 switchover 프로시저가 완료되면 TTL을 원래 값으로 되돌립니다.
oracle 유저로 secondary 데이터베이스 호스트의 Oracle Data Guard broker를 사용하여 복구를 수행합니다.
시스템 비밀번호와 기본 데이터베이스의 고유한 이름이 필요합니다.
```
[oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
DGMGRL> failover to secondary_db_unqname
```
아직 작동 중이지 않은 경우 보조 사이트(새 기본 사이트)에서 Oracle HTTP Server 시스템을 시작합니다.
보조 사이트(새 기본 사이트)에서 관리 서버를 시작하거나 이미 시작된 경우 서버를 재시작합니다.
Admin Server를 시작하면 대기 상태였던 동안 복제된 구성 변경 사항이 적용됩니다.
보조 사이트(새 기본 사이트)에서 보조 관리 서버를 시작합니다.
WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.

검증을 위해 보조 열기

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

참고:

이 작업은 주의해서 수행해야 합니다. 스냅샷으로 변환될 때 데이터베이스에 보류 중인 JMS 메시지가 있으면 대기 사이트의 서버가 시작 시 해당 메시지를 처리합니다. Snapshot Standby로 변환할 때 Primary Database에 보류 중인 작업이 없는지 확인합니다.

oracle 유저로 primary db 호스트에서 Oracle Data Guard broker를 사용하여 보조 데이터베이스를 snapshot standby로 변환합니다.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
show configuration 명령을 사용하여 변환이 올바르게 수행되었는지 확인합니다.
아직 작동 중이지 않은 경우 보조 사이트에서 Oracle HTTP Server 시스템을 시작합니다.
보조 사이트에서 관리 서버를 시작합니다.
보조 사이트에서 보조 관리 서버를 시작합니다.
WebLogic 콘솔 또는 스크립트를 사용하여 보조 관리 서버를 시작합니다.
보조 사이트를 검증합니다.

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

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

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

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

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

참고:
보조 사이트를 검증하는 데 시간이 걸릴 수 있습니다.
보조 사이트에서 관리되는 서버 및 관리 서버를 중지합니다.
보조 WebLogic 콘솔을 사용하여 보조 사이트에서 관리 서버 및 관리 서버를 종료합니다.
oracle 유저로 primary 데이터베이스 호스트에서 Oracle Data Guard broker를 사용하여 보조 데이터베이스를 다시 물리적 standby로 변환합니다.
시스템 비밀번호와 기본 데이터베이스의 고유한 이름이 필요합니다.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
show configuration를 사용하여 변환을 확인합니다.
업데이트된 /etc/hosts 파일을 되돌립니다.
검증을 위해 보조 사이트를 가리키도록 클라이언트의 /etc/hosts 파일을 업데이트한 경우 가상 프론트 엔드 이름이 기본 프론트 엔드 IP 주소를 다시 가리키도록 되돌립니다.

OCI에서 관리 서버의 로컬 복구

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

참고:

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

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

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

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

root 사용자로 APPHOST1에서 다음 명령을 실행하여 네트워크 인터페이스에서 관리 서버의 VIP를 제거합니다.
1. 관리 서버가 실행 중인 경우 중지
2. VIP가 실행 중인 위치를 확인합니다.
```
ip addr show dev ens3
```
3. 네트워크 인터페이스에서 IP를 제거합니다.
```
ip addr del 100.70.8.120/20 dev ens3
```
관리 서버의 VIP를 APPHOST1에서 분리합니다.
1. OCI 콘솔에 연결하여 적절한 지역과 구획을 선택합니다.
2. 컴퓨트 인스턴스로 이동합니다. 컴퓨트, 인스턴스를 누른 후 APPHOST1을 누릅니다.
3. 연결된 VNIC를 누른 다음 관리 서버 VIP가 연결된 VNIC를 선택합니다.
4. IPv4 Addresses를 누르고 관리 서버가 사용하는 VIP를 편집합니다.
5. VIP의 IP 주소와 fqdn 이름을 메모에 저장합니다(예: 100.70.8.120, hydrwls-VIP.midtiersubnet.hydrvcn.oraclevcn.com).
6. Delete Private IP를 누릅니다.
관리 서버의 VIP를 APPHOST2에 연결합니다.
1. 컴퓨트 인스턴스로 이동합니다. 컴퓨트, 인스턴스를 누른 후 APPHOST2를 누릅니다.
2. 연결된 VNIC를 누른 다음 관리 서버 VIP가 연결된 VNIC를 선택합니다.
3. Assign secondary private IP address를 누릅니다.
4. IPv4 주소를 누른 다음 보조 전용 IP 주소 지정을 누릅니다.
5. 이전에 사용된 전용(private) IP 주소 및 호스트 이름 값을 입력합니다. 예를 들어, IP는 100.70.8.120이고 호스트 이름은 hydrwls-vip입니다.
루트 사용자로 APPHOST2에 로그인한 후 다음 명령을 실행하여 관리 서버의 VIP를 네트워크 인터페이스에 연결합니다.
1. 네트워크 인터페이스가 실행 중인 위치를 확인합니다.
```
ip addr show dev ens3
```
2. 관리 서버의 VIP를 네트워크 인터페이스에 추가합니다.
```
ip addr add 100.70.8.120/20 dev ens3 label ens3:1
```
Verifying Manual Failover of the Administration Server에 설명된 대로 나머지 단계를 수행합니다.